2016-04-20 2 views
1

Рассмотрим следующий интерфейс:Обертывание длинный список параметров в качестве единого объекта

public interface SomeRepo 
{ 
    public IEnumerable<IThings> GetThingsByParameters(DateTime startDate, 
     DateTime endDate, 
     IEnumerable<int> categorIds, 
     IEnumerable<int> userIds, 
     IEnumerable<int> typeIds, 
     string someStringToFilerBy); 
} 

Есть ли польза в этом, а?

public IEnuemrable<IThings> GetThingsByParamters(IParameter parameter); 

Где IParameter является объект, определенный как таковой:

public interface IParameter 
{ 
    DateTime startDate { get; } 
    DateTime endDate { get; } 
    IEnumerable<int> categorIds { get; } 
    IEnumerable<int> userIds { get; } 
    IEnumerable<int> typeIds { get; } 
    string someStringToFilerBy { get; } 
} 

Я не вижу никакой пользы в этом IParameter другой, чем это делает его немного более удобным для чтения, но дополнительный уровень сложности Безразлично» Кажется, это того стоит.

Что-нибудь, что мне, возможно, не хватает? Благодарю.

ответ

5

Если это только для этого единственного места, возможно, это не стоит того.

Создание класса само по себе имеет возможно преимущества, но они полностью зависят от именно этого; сможете ли вы его повторно использовать.

Вы можете добавить какой-то проверки ранних данных для вашего IParameters реализации (. Например endDate не может быть раньше, чем startDate - это здравый смысл, вы не должны быть хранилищем объекта, чтобы знать, что).

Если некоторые значения являются необязательными, а некоторые нет, класс Parameters дает вам возможность четко различать эти две категории.

В коде все гораздо проще найти все виды использования Parameters, чем во всех случаях появления исходных пакетов «дата начала/окончания/идентификаторы».

Считается, что читаемость не является незначительной проблемой. Я чувствую, что 6 параметров для метода в два раза больше. И основываясь на опыте, я бы не стал спорить, что он остановится на 6.

1

Вы можете видеть в книге «Чистый код» (Robert C. Martin), что не рекомендуется использовать многие параметры в методе (книга рекомендует используйте не более 3), если у вас есть метод, который требует так много параметров, вам нужно снова подумать о своем дизайне, или это предполагает, что вашей модели нужен еще один класс.

0

Экстремум, которая разрабатывает собственную систему экспрессии, где IParameter имеет строковый оператор ("Equals", "LessThanOrEqualTo", "Plus" и т.д.), а затем имеет массив IParameter[] под названием Children или что-то. Конечно, если вы собираетесь это сделать, почему бы не использовать что-то встроенное, как LINQ или C# Expression? Если это не поддерживается базой данных, и вам нужно использовать строчную фильтрацию, которая является хорошим вариантом (или использовать встроенную фильтрацию/разбор выражений DataTable, если вам не нужна производительность).

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

Это более результативно, потому что теперь вы явно контролируете, какие индексы могут быть запрошены разработчиком конца, выставляя метод, который принимает явные аргументы.

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

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

Смежные вопросы