Сегодня в большинстве методологий используется модельно-ориентированный подход.
Это может быть управляемый доменом или обратный инжиниринг, одна общая точка состоит в том, что они начинаются со статического определения модели. Для домена это домен, выпущенный самим языком разработки. Для обратного инжиниринга он начинается с определения структуры статической модели, например: xsd, wsdl, схема базы данных.
Разработка, основанная на утверждениях, фокусируется на действиях, которые разработчик может выполнять над некоторыми моделями, а не на самих моделях.
Пример: оператор выбора, извлекающий всех членов группы, которыми может управлять пользователь с ролью администратор группы.
Здесь оператор может быть материализован в поисковый запрос с использованием SQL в качестве реализации.
Для разработчика важен запрос и его ввод / вывод, а не модель под ним и… не декоративная технология.
Почему заявление-управляемый-развитие
Несколько статей и ограничений заставляют меня думать, что подход, основанный на утверждениях, может быть гибкой и быстрой альтернативой для разработчиков.
Обычно после определения абстрактной модели, такой как ORM, пользователь должен написать свои операторы UC. Это означает, что еще есть второй шаг.
Модель иногда / часто излишня. Как разработчик, вам не нужно понимать всю сложность модели, прежде чем вы достигнете продуктивности.
Ограничение по стандарту
Как и в статье JOOQ о функции и хранимой процедуре, извлечение метаинформации может достигать некоторых пределов при вводе специфических особенностей поставщика.
Родной DSL
Существует тенденция, согласно которой SQL — единственный DSL, который вам нужен.
Почему вы должны обернуть его другой технологической абстракцией, которая ограничивает его мощность?
До свидания Доменные объекты
… Добро пожаловать в DTO.
Ввод / вывод по сути являются DTO (почему они должны быть точным отражением персистентного слоя?). Эта ситуация является лишь конкретным исключением.
Это исключение широко используется несколькими приложениями / фреймворком (высокая изменяемость, но ограничения)
Примечание: эта статья не предназначена для того, чтобы рассказать о «вечных дебатах» DO vs. DTO. SDD просто приносит новый подход, который не исключает, а дополняет подход DDD / Rev-Eng.
конкретно
MinuteProject для выпуска 0.8.1+ (середина мая 2012 года) предложит средства разработки, управляемые оператором.
- Пользователь сфокусирует одну инструкцию SQL.
- Вывод будет выведен его выполнением.
- Вход будет легко настраиваемым.
пример
Вот простая конфигурация. Оператор-модель — это новый узел.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
|
<model> ... <statement-model> <queries> <query name="get address street"> <query-body><value><![CDATA[select * from address where addressid > ?]]></value></query-body> <query-params> <query-param name="identifier_Address" is-mandatory="false" type="INT" sample="1"></query-param> </query-params> </query> </queries> </statement-model></model> |
Этой конфигурации должно быть достаточно, чтобы получить:
- Входной бин
- Выходной боб
- Выходной список bean
- Все технологии декорирования ex для REST CXF:
- Ресурсный компонент с путем REST
- весенний конфиг
- Родной DAO
Демонстрация будет отправлена в Minuteproject следующего выпуска (0.8.1).
Интеграция с REST в значительной степени основана на операторах: в основном вам просто нужно знать URL + его ввод / вывод.
Вывод
- С SDD вы сосредотачиваетесь на утверждении и I / O.
- Минутпроект упрощает остальное (технология обертки).
Ссылка: разработка, основанная на заявлениях, от нашего партнера по JCG Флориана Адлера из блога минутного проекта .