Используете ли вы инструменты генерации кода?

Question

Используете ли вы инструменты для генерации кода (кроме тех, которые используются для генерации прокси и от дизайнеров, встроенных в Visual Studio)?

Какую часть вашего приложения вы генерируете?

Вы обычно катаете свой собственный генератор? Если да, то какой тип генератора вы пишете (шаблоны asp, coddom и т. Д.). Если нет, то какие сторонние инструменты вы используете?

В настоящее время я работаю над несколькими различными проектами, каждый из которых использует собственный генератор кода, который обрабатывает все, от создания структуры базы данных, бизнес-объектов, DAL и BLL. Мне любопытно, что опыт других людей связан с такими инструментами.

Answer 1

Да, но мы называем их стажерами.

Answer 2

Я нахожусь в философском лагере, который считает генераторы кода "неправильными", потому что они указывают на то, что должно стать частью языка.

Но большая часть этики Pragmatic Programmer заключалась в написании кода, который пишет код, и на практике генерация кода работает хорошо, если сгенерированный код скрыт по умолчанию. Неважно, насколько философски чистым вы хотите быть, язык никогда не будет развиваться так быстро, как проблемы, которые вы хотите решить.

На ум приходит код, который генерируется при создании формы Windows в Visual Studio. Вы можете посмотреть на сгенерированный код, если хотите, но лучше не делать этого. Однако переход на декларативный язык с использованием WPF был более значительным, поскольку он более чист и более надежен в манипулировании декларативным кодом программно, чем императивный.

Они должны были сделать то же самое с классами LINQ-To-SQL. Им нужен декларативный язык для классов, которые просто имеют свойства и не имеют собственного поведения. Вероятно, было бы легче сделать эти классы сущностей динамическими - автоматически изменяющимися при изменении базовой схемы базы данных.

Мы пытались использовать CodeSmith для генерации классов .NetTiers для всех таблиц в нашей базе данных, но столкнулись с двумя проблемами:

1. .NetTiers был раздут, и сгенерированный код был огромен. Я думаю, что инструменты генерации кода делают слишком легким создание существа.

2. Поскольку схема активно развивалась и изменялась, нам также пришлось много регенерировать, и в результате нам было очень трудно поддерживать все под контролем исходного кода, поскольку все файлы регенерировались и заменялись. В итоге я не был уверен, должен ли сгенерированный код вообще находиться в системе контроля версий.

Лучшее место для генерации кода должно быть на этапе компиляции или сборки, а не на этапе проектирования. Когда вы используете анонимный тип или метод в C #, компилятор выполняет генерацию кода на лету. Если вы генерируете код на этапе проектирования, вы получаете кусок stuff , который должен регенерироваться каждый раз при изменении базовых параметров.

Answer 3

Дело не в том, что мы работаем в домене .net / web, но инструменты самодельной генерации кода из различных языков, разработанных для дома, являются важной частью нашей цепочки инструментов разработки. У нас есть два основных таких инструмента (с грамматиками, синтаксическими анализаторами и формальными определениями) и множество второстепенных, основанных на макросах, таких как m4 и perl. Все они генерируют простой C, который компилируется изначально.

Языки, специфичные для предметной области, являются одним из ключевых инструментов повышения производительности труда программистов для любого крупномасштабного программного обеспечения в моем опыте. Если вы создаете такие вещи, как компиляторы, симуляторы или другое очень сложное программное обеспечение с множеством повторяющихся шаблонов, которые вообще не поддерживают базовые языки (что обычно означает переносимый C, а иногда и C ++), инструменты для генерации кода - это то, что вам нужно. Я рассматриваю предметно-ориентированные языки как следующий шаг в обобщении: сначала вы разбиваете общие вычисления на функции (или подпрограммы, чтобы быть историческими), затем вы разбиваете общие функции на шаблоны или обобщения, если такая возможность доступна, и затем вы разбиваете еще больше общности и повторения кода в полноценный пользовательский язык.

Это все о сокращении объема кода, который вы на самом деле пишете, и об удалении любых утомительных повторений и кода без добавленной стоимости из процесса программирования. Как только шаблоны повторятся, примените язык, специфичный для домена!

Answer 4

Я начал сворачивать свои собственные генераторы (доступ к данным, sprocs и т. Д.), Когда я выполнял классическую работу с осами (около 2001 года). Я медленно перешел на CodeSmith, так как с ним было намного легче иметь дело. Я все еще в основном просто генерировал все вещи типа слоя доступа к данным (включая sprocs) для моего кода .NET.

Пару лет назад я сделал переход от генерации макро кода (то есть CodeSmith) к генерации микро кода.

Разница в том, что с CodeSmith я генерировал огромные полосы кода для своего приложения, все общие и все сразу. Это стало проблематичным для крайних случаев и регенерируется при изменении источника для шаблона (то есть структуры таблицы). Я также сталкивался со случаями, когда имелся большой запас несущего кода, который я не использовал, но был сгенерирован из моего шаблона. Все эти методы работали? Может быть, а может и нет. Внедрение и очистка сгенерированного кода было бы огромной работой (т. Е. После более чем одного года на одной и той же базе кода).

Micro Code Generation, напротив, позволяет мне генерировать именно те классы, которые мне нужны, в совершенно правильном сценарии, который я хочу. Основным инструментом, который я использую для этого, является ReSharper. Я делаю это путем написания своих модульных тестов перед написанием моего производственного кода. В этом сценарии ReSharper использует мой модульный тест в качестве шаблона для автоматической генерации скелета для производственного кода. Тогда это просто вопрос заполнения пробелов.

Для доступа к данным я больше ничего не генерирую. Я обнаружил, что хороший O / R M заменяет все, что я использовал для добавления на свой уровень доступа к данным (т.е. NHibernate). Учитывая это, я никогда не буду писать или создавать другой уровень доступа к данным в своей жизни (я отказываюсь).

Кроме того, я получаю преимущества от большого набора юнит-тестов, среди прочего

Answer 5

Поскольку в собственном языке Fog Creek Software, Васаби, встроены генераторы кода времени компиляции, мы используем их для автоматического создания элементов наших классов сущностей, которые отображаются в таблицы базы данных. Таким образом, вместо написания класса с дюжиной различных свойств и методов, мы можем просто написать:

<ActiveRecord("Kiwi")> _
Class CKiwi
End Class

и CKiwi будет иметь Load (ix As Int32), Commit () и поля / свойства для каждого столбца, определенного в его базовой схеме для таблицы Kiwi. Это избавляет нас от необходимости иметь огромные библиотеки O / R M, но позволяет быстро добавлять таблицы в наши продукты.

Answer 6

Генерация кода в духе компиляторов может быть великолепной. Генерация кода в духе «волшебников», как ни странно, оказалась плохой идеей.

Answer 7

Я встретил ActiveWriter пару месяцев назад, и это мне очень помогло, мне нравится гибкость этого подхода, он генерирует частичные классы, которые решают проблемы доступа к данным, и позволяет мне кодировать деловая часть занятий. Я чувствую себя очень довольным, потому что это экономит мне много работы, очень приятно менять схему, заново генерировать и продолжать.

Answer 8

1. Мы используем генераторы кода для исключений
2. Генерация DAO для операций CRUD
3. используйте JAXB для генерации кода
4. Использование XDoclet для создания локальных / домашних интерфейсов EJB
5. Использование шаблонов Velocity для создания документации для бизнес-моделей
6. Использование Apache Axis для создания заглушек WSDL

Answer 9

Я создаю свои собственные инструменты для некоторых задач. Это весело делать и даже экономит время в долгосрочной перспективе. Для очень скучных задач это даже спасает ваше здравомыслие.

Answer 10

Раньше мы использовали CodeSmith для создания наших hibms NHibernate, наших сущностей и некоторых других вещей. Через некоторое время мы устали от этого потока, поэтому мы бросили его.

Генератор T4 является бесплатным и заслуживает изучения для генерации.

Мы по-прежнему используем Castle CodeGenerator для генерации ссылок MonoRail.