Разумно ли мне использовать этот оператор LINQ для получения подмножества элементов на основе динамического подмножества?

Question

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

List<string> lStr = new List<string>() {
    "Category",
    "Document Number", //Case 1 Only
    "Document Title", //Case 1 Only
    "Picture Title", //Case 2 Only
    "Picture Number", //Case 2 Only
    "Issue",
    "Issue Date",
    "Issue Title",
    "Notes",
    "High Priority" //Case 1 Only
};
AddControls(bigDataInput.Fields.OfType<FieldObject>().Where(x => lStr.Contains(x.Title)).ToArray());

bigDataInput - это объект, у которого есть свойство с именем Fields, которое является коллекцией объектов с именем FieldObject. Мне нужно получить подмножество этих объектов FieldObject на основе их заголовка и передать все из них в метод AddControls(params FieldObject[] fields). Проблема в том, какие заголовки мне нужно отфильтровать, зависит от самого bigDataInput. В настоящее время есть только два варианта сценария, и это поля, которые мне нужно отфильтровать.

• bigDataInput Case 1 : категория, номер документа, заголовок документа, выпуск, дата выпуска, заголовок выпуска, примечания, высокий приоритет
• bigDataInput Case 2 : категория, название изображения, номер изображения, выпуск, дата выпуска, название выпуска, примечания

У bigDataInput будут дополнительные поля помимо тех, которые мне нужны. Однако коллекция полей будет иметь только одно из отфильтрованных полей тогда и только тогда, когда мне действительно понадобится поле для этого конкретного случая. Например, в случае 1 нет полей «Название изображения» и «Номер изображения», а в случае 2 нет полей «Номер документа», «Название документа» и «Высокий приоритет». Это ограничение также будет применяться ко всем будущим случаям, сколько бы их ни было.

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

Answer 1

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

В Википедии есть запись о шаблоне Стратегии здесь: http://en.wikipedia.org/wiki/Strategy_pattern

Я немного думаю о потокенапример:

• У вас есть интерфейс с именем IDataInputTransformer с двумя методами: bool AcceptsInput (bigDataInput i) и FieldObject [] TransformInput (bigDataInput i)

• У вызывающего класса есть IEnumerable IDataInputTransformers, который устанавливается каким-либо образом - либо вручную при создании экземпляра, либо с помощью внедрения зависимости или чего-то еще

• После передачи bigDataInput вызывающий класс выполняет итерацию по каждомуIDataInputTransformer и вызывает AcceptsInput с bigDataInput.Если входные данные не принимаются, он просто пытается перейти к следующему и следующему (если никто не принимает входные данные, возможно, генерируется исключение или что-то в этом роде).Если IDataInputTransformer принимает входные данные, вы можете вызвать TransformInput и получить FieldObject [], который будет передан в AddControls

. Вы можете пойти дальше, но это основная идея.Преимущества здесь:

• Удобочитаемость - действительно легко прочитать FinanceDepartmentInputTransformer.TransformInput (), действительно трудно прочитать огромный переключатель
• Возможность изменения - вы можете добавитьновые InputTransformers легко (и это не нарушит удобочитаемость или функциональность)
• Правила изолированы - вы можете легко проверить бизнес-правила в методах AcceptsInput
• Переносимость - вы можете использовать этои в других местах
• Тестируемость - вы можете легко протестировать этот модуль, чтобы убедиться, что он работает правильно