Фильтрация результатов из уровня доступа к данным на бизнес-уровне

Question

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

У меня есть уровень доступа к данным, который отвечает за взаимодействие с различными элементами хранения данных и возвращает POCO или наборы POCO при запросе вещей.

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

Например, у меня есть таблица SQL собак,Мой слой доступа к данным может вернуть этот список собак как коллекцию объектов Dog.Тогда мой бизнес-уровень мог бы выполнять такие вещи, как фильтрация собак младше определенного возраста, или любая другая фильтрация или трансформация, которые должны были произойти на основе бизнес-правил.

Мой вопрос таков.Каков наилучший способ обработки объектов фильтрации на основе связанных записей?Допустим, я хочу всех людей, у которых есть кошки.Прямо сейчас мой слой доступа к данным может вернуть всех кошек и всех людей, но не выполняет никакой фильтрации для меня.

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

Я могувернуть все с обеих сторон и выполнить сопоставление всех себя на бизнес-уровне, что выглядит как большая дополнительная работа и не использует полностью сервер sql.

Я могу написать интерфейс фильтрации данных и, если у меня есть доступ к даннымизменения слоя, этот слой тоже должен был бы измениться.

Есть ли здесь какие-нибудь известные передовые практики, из которых я мог бы извлечь пользу?

Answer 1

Я придерживаюсь мнения, что есть две «причины», по которым вам нужен доступ к данным: Центрирование данных и Ориентация на использование.

• Центрирование данных - это такие вещи, как CRUD и другие распространенные / очевидные вещи, которыеПонятно, что
• Ориентация на «вариант использования» - это то место, где вы определяете интерфейс и подбираете POCO для конкретной цели.[Возможно, я здесь упускаю какую-то общую терминологию, но я имею в виду использование варианта использования]

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

Должны ли кошки и собаки знать друг о друге?Если они существуют в одной и той же модели предметной области и установили отношения внутри этой модели - тогда да, конечно, вы должны иметь возможность делать запросы, такие как GetCatPeople().

Что касается управления сложностью, а не GetCatPeople() у вас может быть более общий метод, который принимает атрибут в качестве параметра: GetPeopleByAnimal(animal).