контроллеры, классы сущностей или дао - что идет куда? - PullRequest
Новая
       21

контроллеры, классы сущностей или дао - что идет куда?

5 голосов
/ 13 июля 2011

С введением Hibernate в моем проекте мой код стал действительно связанным и во многих местах стал образцом (и должно быть наоборот), *?

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

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

Мой класс сущности Пользователь должен иметь отношение, называемое друзьями, которое, по сути, представляет собой совокупность пользователей. Однако вместо этого я должен сопоставить свой класс с коллекцией объектов UserFriendship, каждый из которых содержит ссылку на объект друга, но также и другие конкретные данные дружбы (дату, когда произошла дружба)

Теперь в класс сущности легко ввести пользовательский метод получения, который возьмет коллекцию объектов UserFriendship и превратит ее в коллекцию объектов User. Однако, что если мне понадобится только часть моей коллекции друзей, скажем, как в пейджинге. Я действительно не могу сделать это в объекте сущности, потому что у него нет доступа к сеансу, верно? Это также относится к тому, когда мне нужно сделать параметризованный запрос на отношения. Тот, кто имеет доступ к сеансу, является UserDAO. Итак, я закончил с этим

UserDAO => обычные методы CRUD => getFriends (целочисленное смещение, целочисленный лимит); => группа похожих методов получения и установки, отвечающих за управление отношениями в экземпляре User.

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

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

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

Я глубоко сбит с толку. Более или менее все мои объекты DAO теперь объединяют логику, которая должна быть либо в объектах Entity, либо в контроллерах.

Извините, если мой вопрос немного сбивает с толку. Сложно это сформулировать.

1 Ответ

13 голосов
/ 13 июля 2011

Мои общие правила:

  • в классах сущностей, соблюдайте закон Деметры : не разговаривайте с незнакомцами
  • классы сущностей не должны использовать сеанс
  • Контроллер / классы обслуживания не должны использовать сеанс. Они могут перемещаться в графе сущностей и вызывать методы DAO
  • Методы DAO должны быть теми, которые используют сессию. Их работа заключается в получении, сохранении, объединении сущностей и выполнении запросов. Если для одного варианта использования необходимо выполнить несколько запросов или действий, связанных с постоянством, контроллер / служба должны координировать их, а не DAO.

Таким образом, я могу относительно легко протестировать бизнес-логику, издеваясь над DAO, и относительно легко тестировать DAO, поскольку они не содержат много логики. Большинство тестов проверяют, что запросы находят то, что они должны найти, возвращают их в соответствующем порядке и инициализируют ассоциации, которые должны быть инициализированы (чтобы избежать отложенных загрузочных исключений на уровне представления, где я использую отдельные объекты )

...