Архитектура и пакеты - PullRequest
Новая
       60

Архитектура и пакеты

1 голос
/ 23 декабря 2009

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

До сих пор я группировал классы в пакеты доменов, сервисов и дао. Это представляет модель с объектами POJO / JPA, бизнес-логикой и уровнем доступа к данным.

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

В качестве дополнительного указания я сейчас экспериментирую с веб-приложениями и использую пакет "сервлет" для группировки сервлетов и пакет "веб" для ResponseHeaderFilters, ServletContextListeners и служебных классов. Мне было бы интересно услышать, как обстоят дела с настольным приложением.

Ответы [ 2 ]

6 голосов
/ 23 декабря 2009

Я никогда не слышал о соглашениях об именах пакетов в отношении архитектуры. Единственное соглашение или «наилучшая практика», которые я знаю, заключается в том, что имена ваших пакетов должны начинаться с уникального шаблона, чаще всего сформированного из измененного доменного имени (например, com.mycompany) или около того. Просто чтобы убедиться, что вы не добавляете классы из разных библиотек в один и тот же пакет (пространство имен), что может привести к неожиданным побочным эффектам.

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

com
   .company
           .product
                   .module1
                           .server
                                  .function1
                                            .impl
                           .client
                                  .function1
                           .common
                                  .function1
                                            .impl
1 голос
/ 23 декабря 2009

Я никогда не видел слишком много проблем с этим.

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

используя обратную систему доменных имен (com.company.product ...), вы никогда не столкнетесь с конфликтом даже в своей собственной компании.

Используя пример Andreas_D, в .server и .client вы можете иметь дополнительные 3 или 4 уровня пакетов с десятками или сотнями отдельных пакетов внутри него, если ваш проект достаточно большой, чтобы это оправдать ... но структура при этом уровень имеет тенденцию выходить из дизайна вашего продукта.

Примечание. Этот похожий вопрос , похоже, дает хорошие описания того, как использовать пакеты:

...