Архитектурные проблемы - PullRequest
       23

Архитектурные проблемы

0 голосов
/ 27 октября 2009

Мои классы домена и логика персистенции (Hibernate) находятся в одном проекте под названием модель. Эта банка включена во все мои приложения.
Упаковано com.company.model & com.company.persistance

Другой Utils.jar - содержит общие вспомогательные классы DateTime, String, Thread и т. Д. Это снова включено во все мои приложения.
Упаковано com.company.utils

У меня есть приложение CXF / Spring, которое предоставляет сервисы для манипулирования моими данными. Функциональность CRUD, ВСЕ другие общие функции. Это путь к моей базе данных для любого приложения, разработанного.
Пакет com.company.services и работает на сервере приложений Glassfish

У меня есть другие приложения, которые используют веб-сервисы (Spring Injected) для манипулирования моими данными. Включая веб-приложение, которое будет использовать виджеты YUI и XML / JSON из веб-служб для создания приятного гладкого интерфейса.

Я понимаю, это не совсем вопрос! Я полагаю, я ищу подтверждение того, что именно так другие проектируют свое программное обеспечение. Если моя архитектура имеет смысл, логичный смысл! Очевидно, что существуют проблемы с безопасностью - я хочу, чтобы некоторые приложения имели доступ только к сервису x. Я займусь этим позже.

Ответы [ 3 ]

2 голосов
/ 27 октября 2009

Звучит хорошо.

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

Но пока звучит достаточно хорошо.

Похоже, вы можете сформулировать вопрос отсюда в будущем для некоторого конкретного сценария.

Поскольку это не вопрос, мой на самом деле не является ответом. CW

0 голосов
/ 28 октября 2009

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

com.company.model.core com.company.service.core

com.company.model.billing com.company.service.billing

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

0 голосов
/ 27 октября 2009

Мой единственный комментарий - поместить классы persistence и Hibernate в отдельный модуль; так что модуль model может быть чисто bean / POJO / классами вашего домена.

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

  • project-data - содержит классы доменов и DAO (только интерфейсы)
  • project-services - Службы уровня «Бизнес-логика», использующие интерфейсы DAO.
    • Зависит от project-data.
  • project-hibernate - Hibernate реализация интерфейсов DAO.
    • Зависит от project-data.

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

...