Как правило, если вы используете «истинный» шаблон репозитория, в отличие от других постоянных уровней (например, ActiveRecord или DAO), вам следует стремиться идентифицировать агрегаты вашего домена и создать один репозиторий на агрегат.
Что это значит? Ну, это во многом зависит от вашего приложения, но обычно есть объекты, которые, естественно, являются «родителями» других объектов или являются частью связанной транзакции.
Я думаю, что каноническим примером является система электронной коммерции, в которой у вас есть концепция заказа, а в заказе есть строки заказа, каждая строка заказа - это какой-то продукт и количество, и так далее.
В этом случае объект Order является одним из агрегатных корней системы, и создается OrderRepository.
В этом случае следует помнить, что существует некоторая связь (подразумеваемая или иная) между ордером и его линиями ордеров и так далее. Поэтому части C-UD «CRUD» в репозитории, как правило, должны представлять собой просто один метод, и, как правило, должны просто брать экземпляр этого совокупного корневого объекта и работать с ним (например, repo.Save (order)). Могут быть и другие возможные параметры, но это зависит от вашего значения.
Фактически, вы часто можете решить большую часть C-UD с наследованием (т.е. создать RepositoryBase, который реализует их, используя некоторую известную логику о том, что должно произойти для вашей конкретной схемы персистентности).
Так что это оставляет нам R-часть CRUD. В этом случае вы можете получить тонну методов запроса (GetById; GetByName; GetByCustomerName и т. Д.), Если решите пойти по пути метода запроса. Некоторые люди предпочитают, особенно для простых приложений, предоставлять интерфейс на основе linq (например, IQueryable GetAll ()), к которому затем могут применяться предложения Where. YMMV в зависимости от вашего основного упорства на этом, но это хороший способ для простых приложений, особенно. если вы ожидаете, что ваш поставщик персистентности будет поддерживать linq напрямую.
Наконец, многие люди на самом деле отделяют часть запроса с помощью одной имплантации или другой из шаблона разделения ответственности командного запроса, в котором говорится, что интерфейсы для сохранения и запроса должны быть разными. В этом случае у вас будет Repo с базовыми операциями CRUD (GetById, GetAll, Save, Delete) и другим классом, который запрашивает вещи, основываясь на намерениях вашего приложения.
Надеюсь, это поможет.
Пол