Есть ли шаблоны для модели / классы объекта

Аннотации JPA могут быть приятно в том, что они позволяют вам разместить метаданные метаданные объекта-реляционного сопоставления (ORM) в одни и те же файлы, что и ваши классы объектов, но вы абсолютно правильно, что происходит смешивание опасений, когда вы объедините метаданные JPA с "чистыми" пожётами. Это компромисс.

Однако есть альтернатива. Вы можете использовать конфигурацию ORM в XML-файлах, а таким образом сохраняйте эти детали из ваших классов объектов. JPA предоставляет синтаксис конфигурации XML, но для моих проектов я предпочитаю использовать собственные сопоставления XML Hibernate для добавленной гибкости, которую они обеспечивают. Это может быть не так модно, как аннотационный подход, но в моем опыте он работает довольно хорошо.

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

Ответ на ваш вопрос будет: использовать сервисный слой. Это слой, в котором вы помещаете весь свой бизнес-код. Какую сущность к созданию экземпляра, который DAO использовать, как подтвердить данные, демаркацию транзакции и т. Д.

, поэтому сервисный слой должен быть загрузке нагрузки / сохранения ваших объектов. И вот где вы должны встроить логику о том, что использовать DataSource / базу данных. Используйте инъекцию зависимости весной, чтобы помочь вам с этим. Введите свой выбор DAO, объектов в сервисный слой.

Классы сущности: Собака, CAT

Услуги Услуги: AnimalCenterservice

DAO Classes: AnimalCenterHibernate, AnimalCenterJDBC

Дайте мне знать, если требуется больше объяснений. Только мои 2 цента

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

Сущности с JPA являются хорошим решением, если вы используете JPA. Помимо этих организаций, вы можете иметь больше «сущностей» (Pojos), которые связаны с GAE и т. Д.

Об абстрактной собаке и подклассах, которые кажутся излишним, за исключением того, что если вы действительно надо надо. Если вам действительно нужно, пожалуйста, проверьте объекты DTO: http://en.wikipedia.org/wiki/data_transfer_Object

DTOS используются для передачи объекта в верхние слои (выше DAO) в соответствии с последовательным способом (и Сделайте это сериализуемым) даже при работе с несколькими источниками данных / технологиями в слое настойчивости.

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

В вашем приведенном выше примере я бы сомневался в необходимости предоставлять подкласс, специфичные для хранения хранилищ:

сделать / если классы действительно содержат состояние, относящиеся к тому, как они были сохранены? I.e. Это концепция центральной к классу и, следовательно, достойна использования вашего «одного выстрела» при наследстве (в Java)? Я бы утвердовал, что более полезная иерархия наследования в вашем примере была бы чем-то вроде:

• животное
  • млекопитающее
    • Собака
    • CAT

Кроме того, с дизайном вы предлагаете, вы можете столкнуться с проблемами, если, например, вы хотите сохранить экземпляр , чтобы вздрогнул, но не знаю, Собака - Hibernatedog , GAEDOG , и т. Д. И должен выполнять проверки / накладки на данный момент.

Вы не захотите, чтобы ваш код настойчивости наследулся от классов сущностей, так как это сделает невозможным использование наследования для классов ваших доменных сущностей. Например, если у вас есть HibernateDog, унаследованный от Dog, то вам не будет разрешено иметь Poodle, унаследованный от Dog, не заставляя Poodle быть Hibernate специфичным.

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

Собачьи ссылки (и делегирование) интерфейса DogEntity. Poodle наследует от Dog, PoodleEntity наследует от DogEntity.

HibernateDog реализует DogEntity
. HibernatePoodle реализует PoodleEntity и наследует от HibernateDog.
...
StubDog реализует DogEntity
. StubPoodle реализует PoodleEntity и наследует от StubDog
. ...

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

Доменные сущности будут содержать бизнес-логику, специфичную для данной сущности.