По крайней мере, вы поставили вопрос с правильной точки зрения =)
Обычные причины использования генератора кода приводятся в виде производительности и согласованности, поскольку они предполагают, что решение непротиворечивой и повторяющейся проблемы заключается в добавлении в нее большего количества кода. Я бы сказал, что каждый раз, когда вы рассматриваете возможность генерации кода, посмотрите, почему вы генерируете код, и посмотрите, сможете ли вы решить проблему другими способами.
Классическим примером этого является доступ к данным; вы можете сгенерировать 250 классов (по 1 для каждой таблицы в схеме), эффективно создавая решение для шлюза таблиц, или вы можете создать что-то более похожее на модель домена и использовать NHibernate / ActiveRecord / LightSpeed / [выберите вашу форму] для сопоставления модели расширенного домена на базу данных.
Хотя решение, созданное вручную, и ORM фактически являются генераторами кода, основное отличие заключается в том, когда генерируется код. С ORM это неявный шаг, который происходит во время выполнения и, следовательно, является односторонним по своей природе. Ручное решение требует и явного шага для генерации кода во время разработки, и вероятность того, что сгенерированные классы нуждаются в настройке в какой-то момент, что создает проблемы при повторной генерации кода. Явный шаг, который должен произойти во время разработки, вносит трения в процесс разработки и часто приводит к коду, который нарушает DRY (хотя некоторые утверждают, что сгенерированный код никогда не может нарушать DRY).
Еще одна причина создания кода для создания кода связана с миром MDA / MDE (Model Driven Architecture / Engineering). Я не особо подчеркиваю это, но вместо того, чтобы приводить ряд плохо выраженных аргументов, я просто собираюсь выбрать кого-то другого - http://www.infoq.com/articles/8-reasons-why-MDE-fails.
ИМХО генерация кода является единственным решением в чрезвычайно узком наборе проблем, и всякий раз, когда вы его рассматриваете, вам, вероятно, следует еще раз взглянуть на проблему real , которую вы пытаетесь решить, и посмотреть, есть ли это лучшее решение.
Одним из типов генерации кода, который действительно повышает производительность, является «генерация микрокода», когда использование макросов и шаблонов позволяет разработчику генерировать новый код непосредственно в IDE и вкладывать / вводить свой путь через заполнители (например, пространство имен / имя класса и т. д.). Этот вид генерации кода является функцией resharper, и я интенсивно использую его каждый день. Причина, по которой микрогенерация выгодна в случае сбоя большинства крупномасштабных кодов, состоит в том, что сгенерированный код не привязан к какому-либо другому ресурсу, который должен быть синхронизирован, и, следовательно, как только код сгенерирован, он точно такой же, как и весь другой код решение.
@ Джон
Перемещение создания «базовых классов» из среды IDE в xml / dsl часто наблюдается при разработке большого взрыва - классическим примером могут быть разработчики, пытающиеся преобразовать базу данных в модель предметной области. Если генератор кода не очень хорошо написан, он просто создает дополнительную нагрузку для разработчика, заключающуюся в том, что каждый раз, когда ему нужно обновить модель домена, им нужно либо переключать контекст и обновлять xml / dsl, либо расширять модель домена. а затем перенесите эти изменения обратно в xml / dsl (эффективно выполняя эту работу дважды).
Есть некоторые генераторы кода, которые очень хорошо работают в этом пространстве (дизайнер LightSpeed - единственный, о котором я могу подумать), выступая в качестве движка для поверхности проектирования, но часто
эти генераторы кода генерируют ужасный код, который не может быть поддержан (например, поверхности разработки winforms / webforms, поверхность дизайна EF1) и, следовательно, быстро отменяют любые преимущества производительности, полученные в первую очередь от использования генератора кода.