OSGi: должен ли я иметь комплект Dao?

Question

говорят, что у меня есть модуль бизнес-приложений, например, управление пользователями (um). есть два способа компоновки пакетов (как я могу сказать).

A.datasource, гм-модель, гм-дао, гм-сервис, гм-WAB

B.datasource, гм-апи, ит-осущ

B является то, что я предпочитаю прямо сейчас.

некоторые соображения, я беру:

1. в соответствии с «архитектуры Java-приложений: модульность модели с примерами использования OSGi», я хочу, мелкозернистый более крупнозернистых модулей. Однако, путь A слишком мелкозернистый. Дао должен быть частным. Если другое бронирование комнат в модуле будет запрашиваться у пользователей, оно должно зависеть от модуля (пакета) um-api.
2. Редко кто-то проектирует модули (пучки) um-dao-api, um-dao-jpa-impl, um-dao-jdbc-impl, um-dao-jdo-impl. Может быть, ум-ап, um-ldap-impl, um-avos-delegate-impl - лучший дизайн.
3. datasource - это модуль (пакет), потому что я хочу совершать транзакции между приложениями.

Итак, я не думаю, что Дао должен быть связкой.

любая идея?

thx!

Answer 1

Хотя всегда есть дело вкуса здесь, мой опыт показывает, что следующее может быть хорошей отправной точкой:

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

В вашей ситуации: если вы не хотите, чтобы другие функции использовали материал DAO, сделайте пакет интерфейса и поместите его вместе с реализацией в пакет реализации, но не экспортируйте пакет. Если вам нужно будет позже его экспортировать, переместите пакет интерфейса в пакет API.