Структура приложений

 
 
 
Сообщения:9807
Да, ты понял правильно. Но это только 50% из того, что я говорил =) Жаль, что никто так и не прочел что же такое шаблон Domain Model перед тем, как тратить время впустую занимаясь холивором. Видимо желания спорить больше, чем желания докопаться до сути.
Как я уже говорил выше - собирусь с силами, напишу статью в более расширенном виде, с примерами (даже примеры из собственного опыта вставлю для самых голосливых забияк). А пока призываю не бросаться громкими словами :)
 
 
Сообщения:791
Vermut:
Староверъ:
Продолжим тему. Выше приведен пример слоев приложения, где бизнес логика приложения вынесена в уровень служб. Этот подход будет работать, однако в крупных и сложных проектах у него есть большой недостаток - с течением времени логика будет усложняться и уровень служб будет состоять просто из больших методов, каждый из которых выполняет какую-то бизнес операцию.

В крупных проектах это как раз таки будет иметь преимущество, так как ничто так прозрачно не кластеризуется, масштабируется, перемещается как служба без состояния.

Начнём с того, что "крупный" проект может быть таковым по разным критериям. Одно дело большое количество пользователей и другое - большое количество логики и функциональности и как следствие объём кода.
Например, для ERP-систем более характерна вторая крупность - много логики, немного пользователей. И вот в таких проектах редко доходит дело до кластерности, ибо анемичный процедурный код становится, как правило, не сопровождаем и не модифицируем задолго до перспективы быть перенесённым на кластер.
Если говорить о ERP-системах, то проще решить проблему кластеризации stateful сервисов у проекта с качественным кодом, чем пытаться дорастить анемичный код до возраста проекта, когда потребуется кластеризация из-за нагрузки.
Опять же, stateful сервисы не являются прерогативой Domain Model - они точно так же регулярно присутствуют и в проектах Entity/DAO/Manager.

Vermut:
Староверъ:

    [*]Уровень служб будет переполнен логикой, со временем это превратится в одни костыли и систему уже будет практически не возможно расширять. [/quote] Это не аргумент. Точно так же можно сказать что, угодно например уровень XXX будет переполнен логикой, со временем это превратится в одни костыли и систему уже будет практически не возможно расширять, так как сам по себе код никуда не денется перекочует в тот же уровень XXX.[/quote] Согласен, что про переполнение логикой - Старовер высказался неубедительно. Но, безусловно имеет место быть проблема длинных нечитаемых методов для анемичной модели, которую малореально решить поверхностным рефакторингом, без перехода к Domain Model. Классическая проблема методов анемичной модели - бесконечные switch & if else для методов, реализующих те или иные операции бизнеслогики над сущностями с различными состояниями. К примеру, мы должны реализовать функционал работы с договорами. И нам требуются операции Заключить(Договор), Отменить(Договор), Изменить(Договор), Пролонгировать(Договор). А договоров у нас 3 типа - Договор с Физ. Лицом, Договор с Юр.Лицом, Оферта с Ф.Л. Это значит, что в каждом из методов ДоговорМенеджера нам потребуется ветвление логики Если Договор.тип() == Оферта с Ф.Л, то то-то, иначе если (Договор.тип() == Договор с Физ. Лицом). и так далее. Введение нового типа договора потребует вмешательства во все эти методы. И в итоге, эти методы, если по ходу дела наберется с десяток типов Договоров, будут разрастаться до тысячестрочных простынь. А вот если бы у нас была развитая иерархия наследования (ну или набор классов, реализующих интерфейс Договор), то мы могли бы реализовывать API {Заключить(), Отменить(), Изменить(), Пролонгировать()} в рамках этого интерфейса. Причём, ничто не мешает через Dependency Injection саму реализацию сделать контекстно-зависимой (паттерн Strategy/Template/Visitor на выбор) и реализовать в одном из сервисов. Зато методы реализующие конкретные юз-кейсы станут на порядок более читаемыми + при появлении новых типов договоров нам не потребуется править кучу методов ДоговорМенеджера. [quote="Vermut"] [quote="Староверъ"] [/*][*]Дублирование кода, т.к. многие методы будут выполнять некоторые одинаковые операции постоянно [/quote] От дублирования спасает рефакторинг. [/quote] Спасает, когда дублирование обнаружено. Однако как раз главная проблема анемичной архитектуры Менеджер/Сущность в том, что участки отвечающие за ту или иную логику часто непросто определить и следовательно обнаружить дублирование кода/понять реализован ли уже метод. [quote="Vermut"][quote="Староверъ"] [/*][*]Сложночитаемость и сложнопонимаемость, ибо вся наша логика будет заключаться в больших методах [/quote] Скажу как активно практикующий Data Driven Design, что это абсолютно не так, никаких больших методов в сервисах не существует(у меня), ибо когда приступаешь к новой задаче в имеющем солидную историю постоянно подвергающемуся качественному рефакторингу проекте большая часть функционала уже реализована другими сервисами, и нет причин не пользоваться им повторно. [/quote] см. выше. [quote="Vermut"][quote="Староверъ"] [/*]
  • Процедурный подход к программированию - это трудно заметить, однако да, это будет около-процедурное
    программирование
Почему же тогда такое расслоение описано выше? Ну во-первых, я тогда еще много чего не понимал =) Во-вторых, такое разбиение на слои очень популярно - заметьте, что все вокруг говорят "в классах доменной модели не должно быть логики, не-долж-но!". Это так называемая анемичная доменная модель. Почему так получилось? Мое предположение, навеянное неким Chris Richardson, что эта мода пошла от EJB, т.к. в EJB 2 этот подход был всегда используем (не знаю насчет EJB 3), возможно Sun в те годы развернуло PR-компанию по тому, как должны строиться приложения. Но не будем философствовать, точно я все одно не знаю. Итак, каковы же аналоги?

Я бы просто занялся философией. Ты негодуешь относительно того, что мы не признаем факта что булка хлеба может сама себя испечь, погрузить в грузовик, выгрузить на прилавок, продать или еще хуже того сама себя съесть, да я против подхода наделить груду муки поведением, всегда есть те кто осуществляет действия(СЕРВИСЫ) и что-то над чем осуществляют действия(СУЩНОСТИ или ОБЪЕКТЫ-ЗНАЧЕНИЯ). Если ты против анемичной булки то ты автоматом против того, кто хочет съесть не порезав ножом а просто поломав руками(или другим не предусмотренным в булке способом, и не варвары это вовсе может у них просто ножа нет), а всевозможные способы поедания хлеба в саму булку ты никогда не заложишь.


Отвечу так же аналогией.

В противовес Domain Model паттерну, который пытается реализовать у мальчика Пети метод Покушать(), Поспать(), Искупаться(), анемичная модель реализует семь различных нянек, каждая из которых в зависимости от различных своих причуд насильно кормит мальчика Петю с ложечки, купает и укладывает спать.

При этом среди нянек часто царит разнобой в понимании того что для Пети является здоровой пищей, не каждая в курсе на что у него аллергия, няньки сменяя друг друга не всегда успевают узнать когда он лёг спать и во сколько его будить, умеет ли он плавать, в конце концов.
И в результате "у семи нянек дитя без глазу" - проблема размытых ответственностей.


Особенно начинает просасывать архитектура Сущность/Менеджер для сложных с многочисленными связями сущностей, навроде Отдел/Сотрудник/Заявка/Клиент/Старший менеджер/Выставленный к оплате счёт.

В данном случае, например, не очень понятно где реализовывать метод Поиска сотрудников у которых накопилось много заявок с просроченными платежами для конкретного отдела. (Подсказка - для Domain Model сервисный слой является функционально ориентированным, а не предметно, таким образом распределение идёт по группам юзкейсов, а не степени принадлежности к той или иной сущности).
 
 
Сообщения:2432
Quote:
Начнём с того, что "крупный" проект может быть таковым по разным критериям. Одно дело большое количество пользователей и другое - большое количество логики и функциональности и как следствие объём кода.
Например, для ERP-систем более характерна вторая крупность - много логики, немного пользователей. И вот в таких проектах редко доходит дело до кластерности, ибо анемичный процедурный код становится, как правило, не сопровождаем и не модифицируем задолго до перспективы быть перенесённым на кластер.

А у Вас был реальный опыт, когда такое с Вашим кодом происходило?

Quote:

Если говорить о ERP-системах, то проще решить проблему кластеризации stateful сервисов у проекта с качественным кодом, чем пытаться дорастить анемичный код до возраста проекта, когда потребуется кластеризация из-за нагрузки.

Это исключительно ваши домыслы, если хотите то вот мои:
проще решить проблему кластеризации stateless сервисов у проекта с качественным кодом, чем пытаться дорастить DomainModel до возраста проекта, когда потребуется кластеризация из-за нагрузки.

Quote:

Классическая проблема методов анемичной модели -
бесконечные switch & if else для методов, реализующих те или иные операции бизнеслогики над сущностями с различными состояниями.

Этой проблемы нет, потому что либо сама сущность будет анализировать состояние и в этом случае совершенно ничем не будет отличаться от сервиса, либо Вы будете решать проблему через полиморфизм, тогда как у сервисов в этом случае помимо того же самого полиморфизма, есть еще и возможность делигирования, то есть так как сервис отвязан от данных, то возможности варьировать поток вычислений у него выше и он не ограничивается лишь полиморфизмом.

Quote:

К примеру, мы должны реализовать функционал работы с договорами.
И нам требуются операции Заключить(Договор), Отменить(Договор), Изменить(Договор), Пролонгировать(Договор).

А договоров у нас 3 типа - Договор с Физ. Лицом, Договор с Юр.Лицом, Оферта с Ф.Л.

Это значит, что в каждом из методов ДоговорМенеджера нам потребуется ветвление логики Если Договор.тип() == Оферта с Ф.Л, то то-то, иначе если (Договор.тип() == Договор с Физ. Лицом).

и так далее. Введение нового типа договора потребует вмешательства во все эти методы. И в итоге, эти методы, если по ходу дела наберется с десяток типов Договоров, будут разрастаться до тысячестрочных простынь.

А вот если бы у нас была развитая иерархия наследования (ну или набор классов, реализующих интерфейс Договор), то мы могли бы реализовывать API {Заключить(), Отменить(), Изменить(), Пролонгировать()} в рамках этого интерфейса.
Причём, ничто не мешает через Dependency Injection саму реализацию сделать контекстно-зависимой (паттерн Strategy/Template/Visitor на выбор) и реализовать в одном из сервисов.

Вам что-то мешает развивать иерархию наследования у сервисов? И Dependency Injection на отдельно взятой сущности угробит производительность программы, это вовсе не тот Dependency Injection который срабатывает один раз при создании stateless сервиса и плодами которого мы пользуемся на протяжении всего жизненного цикла приложения.

Quote:

Спасает, когда дублирование обнаружено. Однако как раз главная проблема анемичной архитектуры Менеджер/Сущность в том, что участки отвечающие за ту или иную логику часто непросто определить и следовательно обнаружить дублирование кода/понять реализован ли уже метод.

Нормальный программист всегда видит когда он копипастит.

Quote:

Особенно начинает просасывать архитектура Сущность/Менеджер для сложных с многочисленными связями сущностей, навроде Отдел/Сотрудник/Заявка/Клиент/Старший менеджер/Выставленный к оплате счёт.

В данном случае, например, не очень понятно где реализовывать метод Поиска сотрудников у которых накопилось много заявок с просроченными платежами для конкретного отдела. (Подсказка - для Domain Model сервисный слой является функционально ориентированным, а не предметно, таким образом распределение идёт по группам юзкейсов, а не степени принадлежности к той или иной сущности).

Вы противоречите сами себе. DomainModel чахлая и требует ухода и аппарата искуственного дыхания, воспользоваться ей из разных слоев приложения нельзя(можно но это приведет к копипасту кода осуществляющего жезнеспособность DomainModel между слоями), поэтому Вы выделяете сервисы, которые обеспечивают функционирование модели и следовательно любыми методами модели можно воспользоваться только через сервисы. Так вот если логика в сервисах то на этом многострадальные поиски для размещения метода с успехом можно считать законченными, однако когда логика из сервисов выноситься в DomainModel, то Мы находимся только в начале пути, еше нужно и найти сущность в которой будем реализовывать метод.
 
 
Сообщения:9807
Я все конечно не читал, просто мелькнула в глаза эта фраза:
Vermut:
проще решить проблему кластеризации stateless сервисов у проекта с качественным кодом, чем пытаться дорастить DomainModel до возраста проекта, когда потребуется кластеризация из-за нагрузки
Никто и не говорил, что используя Domain Model, мы отказывается от уровня сервисов (который stateless), напротив - они отлично дружат друг с другом. Да и бизнес класс сам по себе может быть singleton'ом (в смысле спринга) и в него могут объекты тоже инжектиться раз за жизнь приложения.
 
 
Сообщения:791
Vermut:
Quote:
Начнём с того, что "крупный" проект может быть таковым по разным критериям. Одно дело большое количество пользователей и другое - большое количество логики и функциональности и как следствие объём кода.
Например, для ERP-систем более характерна вторая крупность - много логики, немного пользователей. И вот в таких проектах редко доходит дело до кластерности, ибо анемичный процедурный код становится, как правило, не сопровождаем и не модифицируем задолго до перспективы быть перенесённым на кластер.

А у Вас был реальный опыт, когда такое с Вашим кодом происходило?

1. Можно на "ты".
2. У меня был реальный опыт участия в одном проекте, который закрылся именно по причине низкой сопровождаемости - большинство клиентов устало ждать, пока их пожелания к изменению функциональности будут реализованы (это могло занимать по нескольку месяцев). Да, причины были не только в анемичной модели, часто не проводился и более простой рефакторинг, но кардинально решить проблему он бы уже не смог.

А вот я в этом проекте реализовал одно из изменений функционала, в разумные сроки, именно за счёт создания иерархии класса сущности и применения полиморфизма - мне пришлось переопределить лишь пару методов, сохранив в остальном поведение сущности нетронутым и не пришлось менять значительное количество кода при этом.

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

Vermut:
Quote:

Если говорить о ERP-системах, то проще решить проблему кластеризации stateful сервисов у проекта с качественным кодом, чем пытаться дорастить анемичный код до возраста проекта, когда потребуется кластеризация из-за нагрузки.

Это исключительно ваши домыслы, если хотите то вот мои:
проще решить проблему кластеризации stateless сервисов у проекта с качественным кодом, чем пытаться дорастить DomainModel до возраста проекта, когда потребуется кластеризация из-за нагрузки.


Давайте без детского сада.
Никто из критиков DomainModel, насколько мне помнится, не обвинял эту парадигму в проблеме реализации роста сложности логики.
У меня есть подозрение, что как раз у Вас опыта ДМ нет.

Vermut:
Quote:

Классическая проблема методов анемичной модели -
бесконечные switch & if else для методов, реализующих те или иные операции бизнеслогики над сущностями с различными состояниями.

Этой проблемы нет, потому что либо сама сущность будет анализировать состояние и в этом случае совершенно ничем не будет отличаться от сервиса, либо Вы будете решать проблему через полиморфизм, тогда как у сервисов в этом случае помимо того же самого полиморфизма, есть еще и возможность делигирования, то есть так как сервис отвязан от данных, то возможности варьировать поток вычислений у него выше и он не ограничивается лишь полиморфизмом.


Конечно, я говорю о полиморфизме. Именно эта возможность и придаёт основную часть мощи DM. У объектов модели точно так же есть возможность применения делегирования, чем они хуже сервисов?
Я же писал об этом - мы дабы не допустить раздувания логики классов сущностей можем оставить в них лишь наиболее универсальные методы, так сказать общий знаменатель. Остальную логику можно выносить в сервисы, при этом можно частично релизовать возможность обращения к ним по-прежнему через интерфейс класса сущности. Реализуем либо жёстко задавая делегирование в коде, либо через тот же Dependency Injection.

Vermut:
Quote:

К примеру, мы должны реализовать функционал работы с договорами.
И нам требуются операции Заключить(Договор), Отменить(Договор), Изменить(Договор), Пролонгировать(Договор).

А договоров у нас 3 типа
.....

Вам что-то мешает развивать иерархию наследования у сервисов? И Dependency Injection на отдельно взятой сущности угробит производительность программы, это вовсе не тот Dependency Injection который срабатывает один раз при создании stateless сервиса и плодами которого мы пользуемся на протяжении всего жизненного цикла приложения.



1. Иерархия сервисов бесполезна в данном случае, т.к. не позволит применять полиморфизм. В лучше случае - мы сможем воспользоваться перегрузкой методов сервиса по типу параметра. Но это по прежнему принудит нас как минимум добавлять новые методы в класс при добавлении нового типа сущности + раздует количество методов в классе + не даст все возможности тонкой настройки ООП-полиморфизма, навроде абстрактных или финальных методов.
2. Заботы о производительности - это любимое заблуждение противников DM. Начиная тот тех, которые считают, что добавление логики в объекты сущностей повышает используемый ими объём памяти, заканчивая более экзотическими случаями, на вроде вот такой боязни DI. Во-первых, DI на отдельно взятой сущности абсолютно ничтожно повлияет на производительность программы, ибо инициализация ещё одного поля типа Object в каждом объекте сущностей является копеечной нагрузкой для Java. Особенно это будет незаметно, когда в этих объектах уже десяток полей такого типа. Ссылка на объект - это лишь 16 байт в памяти, если мне не изменяет память.
Вот вообще, преждевременная оптимизация производительности - это главная проблема у многих программистов. Есть золотое правило - опмтимизацией нужно заниматься только тогда, когда необходимость этого очевидна и доказана. И делать это руководствуясь не своими соображениями об узких местах, а реальными результатами замеров.

Vermut:
Quote:

Спасает, когда дублирование обнаружено. Однако как раз главная проблема анемичной архитектуры Менеджер/Сущность в том, что участки отвечающие за ту или иную логику часто непросто определить и следовательно обнаружить дублирование кода/понять реализован ли уже метод.

Нормальный программист всегда видит когда он копипастит.


Да, а ещё "нормальному программисту" не нужна документация, ибо он читает код, "нормальному программисту" не нужны тесты, потому что он не делает ошибок в коде. А ещё, "нормальный программист" не существует в природе.


Vermut:
Quote:

Особенно начинает просасывать архитектура Сущность/Менеджер для сложных с многочисленными связями сущностей,
........

Вы противоречите сами себе. DomainModel чахлая и требует ухода и аппарата искуственного дыхания, воспользоваться ей из разных слоев приложения нельзя(можно но это приведет к копипасту кода осуществляющего жезнеспособность DomainModel между слоями), поэтому Вы выделяете сервисы, которые обеспечивают функционирование модели и следовательно любыми методами модели можно воспользоваться только через сервисы. Так вот если логика в сервисах то на этом многострадальные поиски для размещения метода с успехом можно считать законченными, однако когда логика из сервисов выноситься в DomainModel, то Мы находимся только в начале пути, еше нужно и найти сущность в которой будем реализовывать метод.


Я не вижу у себя никаких противоречий, возможно Вы просто меня не до конца понимаете.
Из каких слоёв нельзя воспользоваться? Если говорить о слоях MVC-модели, то те "функционально ориентированные сервисы", о которых я говорю - лишь условное выделение частей всё той же модели из (M)vc, вызванной лишь необходимостью специфики основной части ORM, которые реализуют паттерн Active Record, когда 1 объект сущности представляется одной строкой в соответствующей классу таблице БД.
Ну а сервисы в большинстве случаев занимаются именно логикой, а не хранением данных, или же отображаются в БД через более сложный DataMapper.

Собственно, смысл концепции DM - передать общую для всех юзкейсов часть логики в объекты сущностей, состоит в том, чтобы всё те же сервисы стали содержать более лаконичные и читаемые методы, логика которых будет лежать на одном уровне абстракции. По сути, переход от анемичной модели к DM это не революция, а эволюция и не серебряная пуля, а лишь одна из дробинок "серебряной дроби" - суммарных факторов, складывающихся в успешный проект.
Изменен:28 июн 2011 06:13
 
 
Сообщения:791
Собственно, вот что дядя Фаулер пишет по поводу анемичной модели:

http://www.martinfowler.com/bliki/AnemicDomainModel.html
 
 
Сообщения:52
Вопросы такие.
Если откинуть все ферймворки и допустить что приложение только на сервлетах и jsp (сервлеты - контроллеры, jsp - виды).
1. Куда лучше выносить валидацию данных пришедших от пользователя?
В контроллеры (тоесть сервлеты, акшны) или лучше все делать в уровне сервисов?

Я так полагаю, что контроллер не должен ничего валидировать а просто передать данные из вида в сервис.А сервис, если валидация не прошла, должен уведомить об этом контроллер, что бы тот обновил вид.
Хотя это мое мнение.Опыта не много.

2. Должен ли уровень дао производить какую либо валидацию? Или он должен быть чистым как младенец и полностью доверять уровню сервисов?

И третий вопрос.
3 . Как должны общаться между собой контроллер и сервис? Посредством бинов или в сервис нужно передавать сырые параметры реквеста?

Спасибо.
P.S Естественно, полную валидацию на стороне клиента я исключаю, как небезопастную.
 
 
Сообщения:1517
1-в сервисах. но скорее это будет какаято связанная общая абстракция валидатора
2-никакой валидации в dao как правило нет
3-зависит от приложения. если параметров мало, то можно и сырые, если они повторяют собой какойто объект, то объект, если их много и они не представляют собой объект, то создать объект, который будет их группировать
 
 
Сообщения:148
Господа, вопрос скорее абстрактный.
Что вы думаете о пользе/вреде/необходимости применения jvm-based языков в связке с чистой java для разработки крупных приложений?

В обсуждении уже промелькнуло, что порой расширение функционала может занять значительные сроки, так почему бы не использовать вкупе со, скажем, стройным ядром системы, написанной на java, какой-нибудь, groovy? Ясное дело, производительность при этом, судя по сравнительным тестам просядет, но для выкатывания нового функционала, с последующей оптимизацией особо толстых мест на java - почему бы и нет?

Интересно ваше мнение и опыт.
 
 
Сообщения:1517
если применять к месту, то очень даже на пользу. и ядро системы тоже брезгать писать на том, на чем оно будет лучше не стоит. главное определить для себя что такое "лучше"
 
 
Сообщения:404
Если для "выкатывания нового функционала" требуются такие усилия, что даже язык Java как таковой становится неудобен, то надо в первую очередь задать себе вопрос - а хорошо ли было написано ядро системы? Почему систему становится настолько тяжко расширять? По-моему, это ненормально.

Против Груви ничего не имею, за - тоже. Но стройные системы на одном языке и с общей парадигмой, ме нравятся больше всяких сборных солянок.
 
 
Сообщения:148
С одной стороны согласен, на одном языке это выглядит единообразно и собрано.
А с другой, стороны у меня есть немного опыта в отрасли геймдева. Так вот там очень распространен метод, когда ядро системы пишется на С/C++, ибо производительность, а логика пишется на, скажем, Lua, ибо не самоубицы мы на С++ логику писать. И получается вполне удобно. Java здесь, конечно по сравнению с С++ явно в выйгрыше, но тем не менее.
Вот и мучает меня вопрос, стоит ли изучать groovy, чтобы попробовать такой подход или нет.
 
 
Сообщения:791
WertLex:
Господа, вопрос скорее абстрактный.
Что вы думаете о пользе/вреде/необходимости применения jvm-based языков в связке с чистой java для разработки крупных приложений?

В обсуждении уже промелькнуло, что порой расширение функционала может занять значительные сроки, так почему бы не использовать вкупе со, скажем, стройным ядром системы, написанной на java, какой-нибудь, groovy? Ясное дело, производительность при этом, судя по сравнительным тестам просядет, но для выкатывания нового функционала, с последующей оптимизацией особо толстых мест на java - почему бы и нет?

Интересно ваше мнение и опыт.


Сейчас работаю с Grails - надстройка над Spring с использованием Groovy. С самим Spring до того почти не работал, так что точно не могу утверждать, но тем не менее уверен, что Grails отлично подходит для быстрого прототипирования проекта, который в дальнейшем ожидается реализовывать на Spring.
Переносить будет несложно, имхо.
 
 
Сообщения:128
Также заинтересовался вопросом, как изначально грамотно спроектировать довольно сложную распределенную структуру проекта. Возьмем те же b2b системы, erp, документооборот и т.п. - не просто "сайтик под ключ".

В большинстве случаев структура похожа, на приведенную на картинке ниже:



Но возможны различные вариации. Интересует ваше мнение, возможно даже такие же картинки-схемы, описание того, как Вы видите систему в целом (вашу / чужую / -> хороший пример готового и грамотно спроектированного проекта). Архитектуру.

Выходные, можно и пообщаться на столь, по моему, интересную тему! :D

Староверъ и Krishna - очень много и грамотно все описали. РЕСПЕКТ! И хотелось бы чтобы тема не заглохла и раскрыла свой потенциал :) ))

Вот, ещё - был у нас проект, правда на .NET, там в отличии от большинства проектов на JAVA, методы сущностей DAO - выносились в отдельные классы. Получалось, каждый запрос к БД - отдельный класс, и плюсы в том, что по SVN сразу видно кто чего залил/поломал. И не нужно сравнивать файлы по версионности, чтобы узнать кто менял тот или иной метод для запроса к БД. Также плюсы в том, что явно видно какие запросы имеет та или иная сущность (для каждой сущности - отдельный пакет запросов).
Минус - геморно на каждый запрос писать отдельный класс, на жабке - все пишется в одном классе-DAO конкретной сущности.

Также большинство бизнес-логики выносилось в БД в хранимки.


Но что-то в этом есть :) Как идея?
 
 
Сообщения:2432
Честно говоря .NET и архитектуру обсуждать вообще не хочеца, если у самого главного босса семь пятниц на недели, и каждые полгода смена приоритетов, то что там вытворяют open-source сообщества которые вообще ни чем не ограничены, так как .NET стандартов не предусматривает, то даже страшно предстваить архитектурную выкханалию творящуюся в мире .NET.
 
Модераторы:wedens
Сейчас эту тему просматривают:Нет