Совместное использование служебных объектов между доменом и хранилищем

Question

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

Самое простое решение - использовать методы репозитория с сигнатурами.такие как:

IList<Blah> GetSomething(string _query, 
                         int _page, 
                         int _pageSize, 
                         out int _numPages)

, но это кажется немного анти-OOD.

У меня была идея создать служебную библиотеку dll с ISearchParameter и IPaging объектом, который одновременноУровень домена и уровень хранилища могут быть доступны, это позволит избежать необходимости воссоздавать эти два интерфейса и их имплиментацию в каждом домене и хранилище.если бы оба уровня ссылались на эту утилиту .dll, было бы плохим проектом передавать объекты ISearchParameter между этими двумя уровнями без сопоставления?Если так, есть ли лучшие решения?

Answer 1

1. Используйте шаблон репозитория, чтобы абстрагировать ваше взаимодействие со слоем доступа к данным.
2. Используйте контейнер Inversion of Control для создания своего хранилища, чтобы избежать ссылки из вашего домена на уровень доступа к данным.
3. В этом случае доступ к данным может содержать ссылку на классы вашего домена или на фабрики классов домена, что исключает необходимость в DTO (следуя принципу DRY).
4. Создайте свои интерфейсы без сохранения состояния. Пересекая слои (которые могут стать уровнями), думайте об услугах, а не об объектах. Это предпочло бы более простой подход.
5. Избегайте использования утилиты .dll. Вам действительно нужно только совместно использовать свои интерфейсы репозитория между вашим доменом и уровнем доступа к данным. Вы можете поместить их в свою сборку домена или, что еще лучше, в отдельную сборку.

Answer 2

На мой взгляд, это идеально подходящее решение. В своих проектах я часто использую jqGrid, в котором также есть поиск, упорядочивание и подкачка страниц. Я использую объект gridParameters (определенный на моем уровне инфраструктуры), который передается от контроллера (UI) на бизнес-уровень и уровень данных. Объекты не содержат никаких бизнес-правил, поэтому я не вижу проблем с этим подходом.