Соглашения об упаковке Java - как насчет моделей?

Question

Я начал в PHP, где пакеты не требуются. Мы собираемся построить проект на моей работе на Java, и я рассматриваю архитектуру. Система будет системой управления контентом с 3 уровнями. У нас будут разные модели для разных вещей. Должны ли все модели быть в одном пакете, должны ли они быть разбиты на различные пакеты, сгруппированные со всеми другими функциями, относящимися к их «разделу», или что-то еще полностью?

Answer 1

Если вы программируете для интерфейсов (всегда хорошая идея для системы любого разумного размера / сложности), то решение, которое часто работает хорошо, состоит в том, чтобы проект / пакет содержал определения интерфейса, разделенные разумно; e.g.:

• com.mycompany.cms.domain.foo
• com.mycompany.cms.domain.bar
• com.mycompany.cms.domain.bar.user
• com.mycompany.cms.domain.bar.page

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

package com.mycompany.cms.dataaccess.bar.user;

import com.mycompany.cms.domain.bar.user.CMSUser;

@Entity
@Table("CMS_USER")
public class CMSUserJPA implements CMSUser {
    ...
}

, которая является реализацией CMSUser, которая была соответствующим образом аннотирована для использования со слоем доступа к данным JPA.

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

Answer 2

Нет абсолютных правил для этого. Как правило, я бы сказал, что пакет должен содержать не более 10 и не менее 2 единиц компиляции, но вкусы различаются. Попробуйте найти таксономию, которая позволит вам разделить модели на несколько пакетов, не чувствуя себя искусственно.

Но я бы не ставил модели в один пакет с кодом, который работает с ними. Попробуйте сделать так, чтобы имена ваших пакетов отражали то, что в них происходит, например

com.myapp.model.x
com.myapp.model.y
com.myapp.service.x
com.myapp.service.y
com.myapp.controller.x
com.myapp.controller.y

Answer 3

Я вообще разделяю пакеты слоев:

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

Создание пакетов должно оправдывать тот же контекст их классов.Например, имеет смысл находиться в одном пакете, классах, которые обрабатывают базу данных, с классами, которые являются представлениями данных.

Надеюсь, это поможет