PetroNotC Sharp,

вроде я ещё не очень пожилой :) Спринг бут - это немного другая реализация той же самой идеи. Выделяем основные виды сущностей в коде: SpringBootApplication, Component, RestController и т.п. Можно было бы всё приложение нарисовать в виде модели, а можно прямо в коде пометить каждый класс/метод нужными аннотациями. То же самое с Hibernate: можно пометить классы в коде, можно описать всё в XML. А можно нарисовать модель и из неё сгенерить всё, что нужно.

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

1) Сделать базовые классы (базовая вьюха, базовый контроллер, базовая формочка со списком, базовая формочка с детальной информацией и т.п.) и от них наследовать другие классы - то, о чем вы говорите

2) Для каждой типовой части сделать аннотацию. Разработчики будут аннотировать ими код и в рантайме эти классы будут обрабатываться специальным образом (как в spring, hibernate)

3) Вместо аннотаций использовать какой-нибудь XML, JSON и т.п. - те же аннотации, но во внешнем файле

4) Сделать визуальный язык моделирования для рисования контроллеров, вьюх и т.п. Генерить из этих моделей либо весь код, либо генерить скелет, а остальное дописывать

5) Сделать DSL. Либо генерить из него код, либо интерпретировать его в рантайме.

Вы говорите, что не нужно автоматизировать разработчика. Зачем тогда maven, gradle? Фактически это специальные DSL, которые позволяют описывать один из аспектов приложения: его зависимости от других библиотек, правила сборки. По-моему разработчики только и занимаются тем, что автоматизируют разработку. Только почему-то пункт 5 у них обычно вызывает легкое отторжение и подозрение, пункт 4 - это вообще прямо ужас-ужас, пункт 3 - ну какое-то легаси, пункт 2 - норм, если это делал гуру в фреймвоке, которым пользуются не менее N человек, если по нему не менее X вопросов на stackoverflow и дата последнего релиза не старше 1 месяца, и только пункт 1 можно использовать самим в своих приложениях. А я вообще принципиальной разницы между этими вариантами не вижу, это всё детали реализации. Какой вариант удобнее, тем можно и пользоваться.

Я не могу согласиться. Если в проекте, скажем, в 5 раз меньше кода, то в нём проще разобраться. Скажем 20% кода написано вручную, 80% сгенерено из модели. Сгенеренный код типовой, разбираться в нём не нужно и править его вручную не нужно. Все эти технологии используются в разных компаниях. Я не могу сказать, что их очень много, но обычно это достаточно крупные компании, которые могут себе позволить автоматизацию разработки. Есть целый консорциум Object Management Group, который занимается стандартизацией в данной области. И все эти языки - MOF, OCL, QVTo, MOF M2T и т.п. - это международные стандарты, для которых уже есть готовые реализации.

Велосипед - это скорее писать тонны boilerplate-кода. А если удаётся разложить приложение на какие-то типовые куски, четко всё это описать до такой степени, что аналитики/разработчики в этих терминах (контроллеров, вьюх, репозиториев, форма со списком, форма с детализацией и т.п.) смогут описать приложение и потом это описание практически один в один на верхнем уровне переносится в код, в идеале что-то генерится, либо пишется вручную. Это нормальный промышленный подход. Lombok и spring boot - это хорошо, но обычно недостаточно.

Нет, первый вариант - это 4-ый пункт из моего сообщения, ну либо 3-ий, если dfm можно редактировать в текстовом редакторе (я не помню уже бинарный он или текстовый). А второй - это 1 или 2 из моего сообщения.

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

Сначала нужно в принципе определить (в голове, на листе бумаге) из каких типовых частей состоит приложение (форма со списком, форма с детализацией, ещё какая-то форма, котнроллеры, репозитории, ...). А дальше куча вариантов на выбор:

1) Нарисовать несколько типовых базовых форм в dfm

2) Реализовать в коде несколько типовых базовых форм и от них наследовать остальные

3) Придумать свой графический язык для проектирования форм и всего остального приложения и преобразовывать эти модели в dfm

4) То же самое, но генерить код

5) Вместо графического языка сделать текстовый DSL

...

Я не очень понял вопрос. Модель не обязана быть объектно-ориентированной (типа UML классы с наследованием и т.п.). Модели могут быть какими угодно.

Да, я как-раз об этом говорю. У многих людей слово модель четко ассоциируется с диаграммой классов UML или чем-то подобным. AST для DSL выражения - это тоже модель, просто сериализованная в текстовом виде. JSON, YAML, XML и т.п. - это тоже просто формы представления модели.

Скажем есть 1) диаграмма классов UML 2) Java-классы с JPA аннотациями, 3) XML конфиг для hibernate 4) Excel табличка со списком сущностей и атрибутов 5) Word-документ для аналитика или заказчика, описывающий схему данных (это совсем крамольный пункт). Всё это просто разные формы представления одной и той же схемы данных. Если мы можем легко перейти от одного представления к другому, то какая вообще разница. Какое представление удобнее, тем и нужно пользоваться, а остальные будут производными от него. Но это касается не только схемы данных, но и всего приложения.