http://forum.vingrad.ru/forum/topic-267783.html
хотелось бы обсудить тут.
Цитата(COVD @ 25.7.2009, 19:46  ) |
| Лучше набор независимых приложение, компонентов, модулей. Но, наверное, это не всегда возможно. |
прошу прощения, но меня немного "возмутил" ответ COVD.
скажи, а разве это вообще возможно? каким образом можно поистроить jee приложение в котором общие интерфейсы, например, на DAO? компонентная сборка гарантирует сначала дупликацию кода, а потом и в последствии (по другому не получится) его разницу при абсолютно идентичных задачах.
если слишком тяжело объяснил, попытаюсь объяснить траблу, на которую я не знаю ответа.
допустим есть
(1)
base
dao
manager
проекты, каждый из них собирается maven-ом как *.jar
при такой архитектуре не возможна компонентная архитектура, т.к. какой бы компонент не строился, всё размажется по этим трём подпроектам.
приведу другой пример
(2)
component1
component2
component3
архитектура на первый взгляд кажется идеальной, а каким образом решать траблы с общими интерфейсами? в каждом пакете используются DAO и не плохо было бы иметь общий интерфейс на CRUD операции. ладно, скажешь ты, заведём ещё один проект, и положим туда интерфейсы:
base
component1
component2
component3
а как же быть теперь с утилитами? тоже положить в base? у компонентов начинаются зависимости между собой, как только они начинают интерагировать друг с другом, зависимости на entity уровне, manager-ах, утилитах и других "паттернах" программирования.
при малом коде, всё кажется идеально, но как только код растёт, все компоненты переплетаются друг с другом и хотя они могут иметь структуру зависимостей в виде дерева, чем выше компонент в дереве, тем всё тяжелее и тяжее от него отказаться. но мы ведь говорили о компонентах? типа, взял вытащил и туда другой вставил и всё работает? хорошо, когда пишутся framework-и, типа velocity, log4j и т.д. в них чётко разделена логика. НО... она возможна вообще в jee мире??
------------
пример из жизни:
мы пишем некое приложение jee на spring. мы для сборки проекта использовали ант. само приложение собирается как бы из двух частей. дабы облегчить работу верстальщику мы сделали для него view и некие моки, которые просто описывали manager-ы (а не прямая работа с базой данных). всё было зашибить, пока проект не начал дико расти по всем направлениям. пришлось делить подпроекты. сначала из двух стало четыре. код ант-а стал просто беспощадно почти дублироваться и в нём, как всегда, были лишь некоторые мелочные различия. это дошло до того, что подправление каких-то мелочей в ант-е, начало занимать часы. не хватка все различных плагинов (которые в ант-е нужно подключать руками) начало тока раздувать ант. а ведь у нас ещё и не было написано половины приложения. тогда мы решили перейти на мавен, как спасение от ситуации.
ну чтож, типа всё просто, у нас интерфейсы чётко соблюдены, попробуем построить компоненты. через 4 дня беспощадных и продуктивных усилий мы сдались. файлы так переплитались через интерфейсы, что стало не возможно их разделить и построить хоть какое-то "приличное" дерево. это была попытка номер (1)
набравшись немного опыта, Алекс начал делить файлы уже не как компоненты, а как layer-ы: dao, manager, velocity, spring, base и т.д. размельчив примерно на 25 пакетов, проект из простой структуры вырос в какую-то непонятную машину. так прошло ещё дня четыре.
поняв, что пакетов много и попытавщись притащить за уши идею номер (1) с новыми мыслями и наработками мы сдались через дня 4 заного.
следующая попытка вернула нас на layer-ы + (только частичная!) компонентная структура. подпроектов стало 11, разделение стало чёткое и некоторые вещи просто объеденены.
теперь, что я хотел сказать. компоненты у нас в проекте по дереву стоят в самом вверху иерархии, а это значит, так просто заменить их уже наврядли удастья. они врасли в проект, хотя там и навалом интерфейсов для разделения.
как же строить JEE приложения?
пс. заказал пару книг по паттернам, может быть там найду светлые идеи, но решение в данной ситуации не кажется мне реальным. или?
, хотя, конечно, смотря какое приложение ты пишешь. но у нас все модули тесно взаимосвязаны друг с другом 
