Во-первых, классов не 1800, а меньше. Потому что критерии можно использовать повторно. Например, критерии для постраничной выборки можно применить к запросам разных сущностей. Во-вторых, как я уже писал, в случае классов можно эффективно использовать наследование для борьбы с дублированием. Можно строить целые иерархии запросов, помещая в базовые классы общую логику. Как такое повторить с репозиторием?
Я хотел сказать, что код вида
var account = Query.For().With(new LoginCriterion(login));
напоминает rich-data-access синтаксис аля linq2sql, IQueryOver (NH) и т.п. Например, для IQueryOver:
var account = QueryOver.Of().Where(x => x.Login == «userName»).GetSingleObject();
например, когда число методов в каком-либо репозитории превысит 9000. На самом деле разделение единого интерфейса на множество объектов имеет несколько плюсов:
1. один сложный объект разбивается на множество мелких, которые легче тестировать
2. инкапсуляция в объекты позволяет использовать наследование для устранения дублирования (в обычном репозитории чтобы устранить дублирование в методах пришлось бы использовать делегаты/лямбды)
Да, видимо всё-таки речь идёт не о модульных, а об интеграционных тестах. Но даже в этом случае принято состояние системы эмулировать напрямую (например, записью нужных данных в базу), а не вызовом последовательности тестов.
var account = Query.For().With(new LoginCriterion(login));
напоминает rich-data-access синтаксис аля linq2sql, IQueryOver (NH) и т.п. Например, для IQueryOver:
var account = QueryOver.Of().Where(x => x.Login == «userName»).GetSingleObject();
1. один сложный объект разбивается на множество мелких, которые легче тестировать
2. инкапсуляция в объекты позволяет использовать наследование для устранения дублирования (в обычном репозитории чтобы устранить дублирование в методах пришлось бы использовать делегаты/лямбды)