Дизайн программы - пакет по функции против слоя или оба?

Question

Я нахожусь в стадии разработки веб-приложения, которое позволяет пользователям создавать запросы работы, а работники - уделять время этим запросам. Приложение также будет иметь функции отчетности для супервизоров для получения ежедневных итогов, отчетов и учета затраченного времени, «распределения затрат».

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

Что я сейчас думаю о пакетах по функции:

1. Запросы - CRUD запросы, назначение, добавление номеров счетов и т. Д. ...
2. Рабочее время - ежедневное CRUD-время для пользователей по запросам, праздникам, тренировкам или встречам
3. Распределение затрат - создание отчетов, учет того, что хотят бухгалтеры ...

Внешним интерфейсом будет сервер Tomcat и JSP. И серверная часть будет базой данных Oracle с EclipseLink, выполняющей постоянство.

Мой вопрос:

В моем понимании «пакет за функцией» сущности и DAO включаются в пакет, связанный с ними. Распределение персистентного слоя по нескольким пакетам. Оставление пакетов для вызова сущностей из других пакетов. Со всем перекрытием это действительно функционально? Там не будет никакой изоляции между пакетами. Каковы плюсы и минусы использования пакета по функциям? Будет ли хорошим дизайном идти с дополнительным постоянным слоем? Или я понимаю это совершенно неправильно?

Answer 1

Я бы предложил начать собирать вещи на основе бизнес-сущностей.И там вы можете делить вещи по слоям.

При таком перекрытии это действительно функционально?

Я занимаюсь этим долго.Я не вижу каких-либо серьезных проблем с этим подходом.Вы должны выяснить, что нужно отделить и на сколько это нужно отделить.Например, вызов постоянного метода orders из пакета customer с использованием API, предоставляемого orders, вполне подходит для меня.

Каковы плюсы и минусы использования пакета с помощьюособенность?

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

Было бы неплохо создать дополнительный слой персистентности?

Посмотрите на этот поток SO Я обнаружил, что JPA или что-то подобное не поддерживает шаблон DAO .

Дальнейшее чтение

• Универсальный репозиторий иDDD

Answer 2

5 лет спустя ...

(музыка в фоновом режиме)

Представьте себе эту нелепую ситуацию:

Управляющая компанияКомпания по программированию, Компания по работе с персоналом и Маркетинговая компания, где в компании «Программисты» будут работать только программисты, а не менеджеры, маркетологи или сотрудники отдела кадров;

Мы не хотели бы разделять сотрудников по их профессиивместо того, чтобы организовывать (самосогласованные) команды, или мы?

Объединение материала по тому, чем оно является, а не по тому, что оно делает, заставит вас прыгнуть всего лишь 10 раз к тому месту, где вы находитесьищу.

Разве это не выглядит просто сексуально?Посмотрев на структуру, вы уже можете сказать, о чем приложение.Не удовлетворены? Читать статью полностью .

Answer 3

Если бы я выбрал между двумя пакетами по функциям против пакетов по слоям.Я бы выбрал пакет за слоем.

По нескольким причинам,

• В многоуровневой архитектуре должны быть четко определены интерфейсы / зависимости между слоями, соответствующая упаковка будет быстро выделена, если вы неили нет зависимостей
• Он изолирует зависимости в одном слое (например, персистентность с использованием Oracle) от других ваших уровней.
• Я считаю более понятным думать о каждом слое изолированно

Но, чтобы ответить на ваш вопрос "Особенности против слоев" или "и то и другое", я бы сказал, что оба пакета в основном по слоям, а затем по функциям.