Почему для каждой сущности должны быть отдельные картографы mybatis?

Я разрабатываю небольшое приложение, использующее аннотации MyBatis и интерфейсы картографов. Во всех примерах, которые я видел на MyBatis, включая официальный веб-сайт, для каждой сущности создается отдельный класс сопоставления. У меня есть две сущности, Foo и Bar, и две БД, каждая из которых содержит эти сущности. Итак, в настоящее время часть структуры моего проекта выглядит так:

model
├── bar
│   ├── Bar.java
│   ├── DB1BarMapper.java
│   └── DB2BarMapper.java
└── foo
    ├── Foo.java
    ├── DB1FooMapper.java
    └── DB2FooMapper.java

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

model_new
├── Bar.java
├── Foo.java
├── DB1Mapper.java
└── DB2Mapper.java

Здесь средства отображения БД будут содержать методы для доступа к объектам как Foo, так и Bar (и возвращать соответствующие объекты POJO) каждый.

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

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

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

Вы можете создать общий суперкласс для DB1 и DB2, а затем небольшие конкретные подклассы для Foo и Bar, которые расширяют указанные суперклассы.

Lino 10.08.2018 15:34
4
1
272
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Более разумно хранить по одному сопоставителю на объект для каждой базы данных. ПРИМЕР: Если в какой-то момент вы измените способ сопоставления вашего FOO, вы измените только этот сопоставитель объектов и не коснетесь другого, также если вы хотите добавить / удалить один объект в / из сопоставления. У вас будет более понятный и простой в обслуживании код.

Ответ принят как подходящий

Нет ничего плохого в том, чтобы использовать один картограф для нескольких объектов. Картографы - это своего рода модули с логикой уровня DAO. И те же критерии, что применяются к разделению другого кода на модули, применяются к мапперам, а именно: вещи в одном маппере должны иметь высокую связанность, а вещи в разных мапперах должны иметь низкую связь.

В основном структура картографов отражает структуру приложения. Как и в большинстве случаев, для каждого module существует сопоставитель с широким определением module. Это не обязательно означает картограф на класс. Это может быть сопоставитель для каждого типа базы данных, если имеет смысл разделить код в приложении по типам базы данных.

Причина, по которой сопоставление по классам сущностей популярно, потому что преобразователи по классам - это естественный способ разделения преобразователей, поскольку класс сущностей является естественным модулем приложения. Но это не всегда так и не всегда самый удобный способ делать шпагат. Во многих случаях имеет смысл иметь сопоставитель для каждого совокупность, который является одним сопоставителем для кластера объектов домена, которые можно рассматривать как один блок / модуль.

Другие вопросы по теме