Здравствуйте, AndrewVK, Вы писали:
AVK>Мне уже надоело намекать, поэтому спрошу прямо — когда ты наконец опишешь то, что предлагаешь?
Сразу бы спросил прямо, чай не в прятки играем. А то уже с темы съехали.
Постановка задачи: есть функциональные требования. В требованиях описаны сценарии бизнес-логики. Из этих сценарием аналитик выделил объекты бизнес-логики. При этом есть замечание, что состав полей объектов может меняться со временем, кроме того объекты могут получаться из разных источников.
Метод состоит в том, чтобы описывать объекты в виде XML (что-то вроде UML-описания, только со своими особенностями), после чего наложением различных XSLT-шаблонов получать скрипты создания базы, исходники классов и интерфейсов DAL-уровня и заглушки для классов бизнес-уровня. Метод обкатан и готов к тому, чтобы им делиться.
Я видел местами применение XSLT для генерации исходников в других местах, эта идея не нова. Но возможно в таком приложении она упростит кому-то жизнь.
P.S. Кстати первая часть генерила классы именно для NHibernate, но в других решениях я предпочёл NHibernate не использовать.
Здравствуйте, Darth Jurassic, Вы писали:
DJ>Метод состоит в том, чтобы описывать объекты в виде XML (что-то вроде UML-описания, только со своими особенностями), после чего наложением различных XSLT-шаблонов получать скрипты создания базы, исходники классов и интерфейсов DAL-уровня и заглушки для классов бизнес-уровня. Метод обкатан и готов к тому, чтобы им делиться.
Метод этот называется DSL — Domain Specific Language. Про него масса чего написана и есть море инструметов. Те же новые DSL Tools от Microsoft. А XSLT там или TT, дело десятое. И с ORM это пересекается слабо. Как и с SRP. Разный уровень.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Darth Jurassic, Вы писали:
DJ>Метод состоит в том, чтобы описывать объекты в виде XML (что-то вроде UML-описания, только со своими особенностями), после чего наложением различных XSLT-шаблонов получать скрипты создания базы, исходники классов и интерфейсов DAL-уровня и заглушки для классов бизнес-уровня. Метод обкатан и готов к тому, чтобы им делиться.
Проект на котором обкатывался этот метод уже завершен? (праздный интерес)
Дело в том, что наверняка вся кодогенерация заточена под специфичные требования проекта и может быть применена только для проектов со схожими требованиями. Кроме того, когда речь зайдет об гранулировании обращений к БД, более-менее сложных запросах, lazy load и прочей оптимизации, то скорее всего, метод придется выкинуть.
В общем, универсальных решений не существует. И перед тем, как изобретать новое универсальное решение, следует поинтересоваться судьбой прочих. Хотя бы для того, чтобы представлять, чем Ваше решение лучше подходит для решения вопросов вечности
Здравствуйте, Darth Jurassic, Вы писали:
DJ>>>2. Приветствуются аргументы за и против. C>>Аргумент простой: single responsibility principle. Т.е. класс данных не должен заниматься загрузкой себя из базы.
DJ>Какие риски я преобретаю, нарушая этот принцип?
Сложность тестирования, в частности, при написании юнит тестов.
Здравствуйте, samius, Вы писали:
S>Проект на котором обкатывался этот метод уже завершен? (праздный интерес)
Два проекта завершены, два в процессе разработки.
S>Дело в том, что наверняка вся кодогенерация заточена под специфичные требования проекта и может быть применена только для проектов со схожими требованиями. Кроме того, когда речь зайдет об гранулировании обращений к БД, более-менее сложных запросах, lazy load и прочей оптимизации, то скорее всего, метод придется выкинуть.
Шаболоны приходилось дорабатывать для полного соответствия, так что ещё есть куда развиваться. В частности приходилось делать динамическую загрузку и выгрузку объектов. Но сейчас реюзабилити процентов 90. Хотя минус есть: для остальных 10% надо знать XSLT.
S>В общем, универсальных решений не существует. И перед тем, как изобретать новое универсальное решение, следует поинтересоваться судьбой прочих. Хотя бы для того, чтобы представлять, чем Ваше решение лучше подходит для решения вопросов вечности
Это решение не универсально, просто оно автоматизирует много рутинной работы.
Здравствуйте, Darth Jurassic, Вы писали:
S>>В общем, универсальных решений не существует. И перед тем, как изобретать новое универсальное решение, следует поинтересоваться судьбой прочих. Хотя бы для того, чтобы представлять, чем Ваше решение лучше подходит для решения вопросов вечности DJ>Это решение не универсально, просто оно автоматизирует много рутинной работы.
Все же почитайте LINQ to SQL, Entity Framework. Думаю, что именно эти технологии объясняют пониженный интерес к Вашей автоматизации рутиной работы. Хотя, они тоже, к сожалению, не универсальны.
Всем спасибо, много полезных советов. Отднльное спасибо за ссылку на LINQ to SQL и отдельнейшее спасибо за EJB Entity Beans with BMP Architecture — это действительно близко к тому, о чём собираюсь писать.
В общем, начинаю работать. Если будут ещё какие-то замечания/уточнения — милости просим.
