скажи, у вас в проекте всё разделено чётко, структурно и всё лежит идеально грамотно?  

возьмём два "компонента": account и payment, надеюсь понятно, чем занимается каждый из них  payment получается зависит от account-а, ему нужен entity account, чтоб работать с ним, например, выставлять счёт. если так, то payment-у нужно также, либо написать отдельные методы на DAO и manager-ы в account-е, либо написать (частично дупликаты в payment-e). так?  если так, то на этих участках, payment уже начинает прилипать к account-у и пока только двумя вещами: entity и manager  при расшерении логики, payment начёт прирастать к account-у, я не говорю, что account станет дёргать payment, хочешь этого или нет   приложение растёт и за payment рано или поздно схватится ещё какой-то "компонент", и на этом этапе вырвать какой-то из компонентов не являющийся последним в цепочке (дерево) уже становится невозможно или не просто  

Вообще уникальный "core" в распределенной системе - слабое место. Полностью его устранить сложно, но логично его максимально облегчить для ускорения рестарта в случае аварии, чтобы не подвешивать всю систему. Что касается базы, то да, компоненты открывают собственные соединения с базой. Поскольку ресурсы относительно независимые, то компоненты работают с разными таблицами (можно было бы и базу разделить на части). Если же есть конкурентный доступ к одной таблице из разных компонентов, то блокирование таблицы при необходимости осуществляется самой базой. У нас база данных далеко не основной источник данных, поэтому оптимизацией особо не занимались.   

Если я правильно понял, то конечно "дублирование" неизбежно. В том смысле, что если сделать два независимых приложения "account" и "payment", то обоим требуется описание обьекта account. Но, возможно, для "payment" нужен не полный обьект account, а только его некоторые свойства. Оба приложения загружают нужные обьекты account из одной таблицы. Если приложение "payment"  делает успешную транзакцию, то надо освежить копии обьектов на клиенте и в серверном кеше (если таковой есть). Тот, кто инициирует изменение, т.е. транзакцию (это клиент наверное), тому и удобнее инициировать обновление копий.     

Это сообщение отредактировал(а) COVD - 25.8.2009, 17:54

Я вот только в упор не понял почему account и payment являются компонентами.  Давайте уж тогда определятся с терминологией или подробнее расскажите что такой account и payment.

Хм.. я думал модуль == компонент.

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




вот, и я об этом. хр*нова получается.. "я не согласен. а может быть мы поищем другие варианты?" (с) Гришковец  


-----

тогда я за то, чтоб поговорить, что же такое компонент и как добиться "меньшей" работы при "лучшем" построении   

тогда ищите  


компонент приложения - это плагин (Эклипс) или модуль (Нетбинс)
компонент системы (распределенного приложения) - приложение .

Это сообщение отредактировал(а) COVD - 26.8.2009, 12:33

всё.. похоже тема захлебнулась в безвыходности..   
пс: я так и не понял, что же такое компонент, как его так магически строить  

Нет уж, давай порисуем (с)

Я не могу дать точного определения компонента, но могу сформулировать ряд, на мой взгляд, ключевых признаков.

•  Компонент - часть приложения (для простоты), легко идентифицируемая и обладающая конкретным функционалом и границами ответственности.
•  Связанность частей компонента (high cohesion) гораздо сильнее чем связь между компонентами (low coupling). Зависимости между компонентами осуществляются через малый набор четко определенных интерфейсов.
•  Компонент предполагает независимый жизненный цикл: сборку (с учетом разрешения зависимостей между компонентами), тестирование (как правило через мокирование других компонентов) и деплоймент (в идеале).

Не надо путать компонент и слой/уровень/layer.
Портлет может быть компонентом на уровне представления в портале. Слой - это функциональное назначение всех компонентов, которые в нем находятся. Это все равно, что рассуждать чай более горячий, чем сладкий.
Компонент позволяет просто решать некоторую задачу. Он имеет некоторую функциональность. Слой позволяет разбить систему на разные зоны ответственности, гед работают компоненты для решения конкретных задач этого слоя. Один слой занимается сохранением данных используя определенные компоненты. Другой слой - бизнес-логика. И он использует другие компоненты.

AntonSaburov, так как я понял, проблема в том что при нарезке по слоям (layer), когда мы вносим новую функциональность нам приходится проводить изменения в каждом из слоев. А хотелось бы, чтобы новый функционал приходил единым "куском". Ежели нарезать поперек, по функционалу, то, во-первых, в каждом "куске" мы повторяем структуру всех слоев, во-вторых, "куски" начинают обрастать перекрестными зависимостями друг с другом. Как уже ранее предлагалось, можно скомбинировать "нарезку". Низкий уровень порезать по-layer'но сформировав некие base-компоненты. А высокоуровневые резать по функционалу.

всё, что сказано, мне понятно.. но нет конкретики, а есть, если то это, а вот если так то то.. у нас приложение, например, делется на следующие модули:

вся структура построена на мавене:

- parent            // parent мавен
- base               // некая часть, модуль, что не вошёл ни в один другой модуль не обязан лежать в "корне" дерева
- category        // "компонент" для работы с категориями
- entity              // entity
- dao                 // слой DAO
- manager        // слой manager-ов
- html                // js, images, css, html для верстальщика
- spring             // настройка спринга, контроллеры и т.д.
- install             // инсталяция приложения и т.п. вещей
- selenium       // тесты на основе selenium
- view               // собирает view для верстальщика
- web                // собирает полностью приложение

с запусом различных профилей имеем различные приложения. как видно, из такой структуры невозможно ничего выдернуть. каждая новая "страница" размазывается по практически по всем модулям. потом она обрастает перекрёсными ссылками и "навеки" в системе. а какую структуру приложения избрали вы?   поделитесь своими best practices   

Продолжу свои рассуждения   

Из цитаты  следует, что разделять приложение на компоненты можно в двух направлениях. Выделяем фрагмент приложения, решающий определенную задачу (подробнее выше в посте fixxer'a) и оформляем его в виде или отдельного приложения или в виде плагина-модуля. В первом случае строим распределенную архитектуру. Во втором - плагинно-модульную.

Если разделяемое приложение - клиент, то для него имеет смысл только второй вариант. Клиентское приложение работает на одном компьютере. Развертывание распределенной системы на одном компьютере не дает преимуществ. Скорее, недостатки.

Если разделяемое приложение - сервер, то формально для него годятся оба варианта. Однако первый вариант (распределенная архитектура) на мой взгляд предпочтительнее. И вот почему. Серверное приложение работает в условиях, когда нормальным является наличие несколько компьютеров, обьединенных в локальной сети. Поэтому распределенная архитектура здесь проявит все свои достоинства, особенно ценные для режима работы 7/24, типичном для серверов. С другой стороны, серверное приложение обычно создается и контролируется только владельцем. Трудно представить, что внешние команды по собственной инициативе создают компоненты для серверного приложения. Это является обычной практикой, например, для открытых IDE. И плагинно-модульная архитектура, на мой взгляд, разработана именно под такой сценарий. 

Плагинно-модульные платформы формализуют (а следовательно, автоматизируют) процесс подключения, т.е. поиск модулей и проверки соответствия версий, интерфейсов.  Серверное приложение тоже может создаваться усилиями нескольких коллективов, но создаваемые ими компоненты в условиях сервера наверное практичнее развертывать как отдельные приложения. Универсальным средством интеграции приложений на сервере являются системы или шины сообщений (messaging). Они позволяют обьединять решения от независимых производителей без привязки к платформе. Не имеет смысла создавать плагины, когда есть перспектива необходимости масштабирования приложения - в случае успешного развития бизнеса нагрузка на сервер возрастает, покупаются дополнительные компьютеры. Распределенное приложение проще масштабировать чем монолитное.      

Поэтому прихожу к заключению, что разделение на компоненты для клиентского (standalone) приложения осуществляется переходом на плагинно-модульную архитектуру. Для серверного приложения предпочтительным является переход к распределенной архитектуре.    

Не-не-не. Так мы за деревьями леса не увидим. Давай вернемся к нашим баранам (account и payment) и на их примере попробуем разобраться. Расскажи на их примере, какая будет архитектура. Поподробнее только, с классами и т.п.

COVD, это вот всё.. конечно, понятно сказано.. цитата из книги: "вот некий пример, как же хорошо наш пример попадает в нашу архитектуру!! кто бы мог подумать".

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

Добавлено через 2 минуты и 46 секунд


следуя архитектуре которая у нас есть сейчас, account и payment "размажется" по пакетам base, entity, dao, manager, html, spring, selenium