Как обращаться с массивной фабрикой более чистым способом

Question

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

В моей системе есть enum с 250 участниками [один член представляет собой отдельный выпадающий список]. Чтобы заполнить раскрывающиеся списки в любом данном окне, эта форма отправляет элементы перечисления, которые относятся к необходимым раскрывающимся спискам, и возвращается раскрывающаяся информация.

Другими словами, скажем, у нас есть 3 окна. В окне A есть раскрывающиеся списки X, Y и Z. В окне B есть раскрывающиеся списки W, X и Y, а в окне C есть раскрывающиеся списки T, U и W. Мой список DropDownType будет состоять из T, U, W, X, Y, Y и Z. Таким образом, для указанного окна, учитывая раскрывающиеся списки в этом окне, я запрашиваю данные для отображения в этих раскрывающихся списках.

Это упрощенный пример, потому что мое приложение состоит из> 250 различных раскрывающихся списков.

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

    switch (dropDownType)
    {
        case DropDownType.T:
            return (from t in dataContext.GetTable<TableOne>() 
                    select new DropDownDto 
                               { 
                                   DropDownDisplayName = t.ColumnA,
                                   DropDownValue = t.ColumnB
                               }).ToList();
        case DropDownType.U:
            return (from u in dataContext.GetTable<TableTwo>() 
                    select new DropDownDto 
                               { 
                                   DropDownDisplayName = u.ColumnC,
                                   DropDownValue = u.ColumnD
                               }).ToList();
        // etc...
    }

Поскольку у меня так много членов в этом перечислении, кто-нибудь знает о более изящном способе кодирования этого? Как вы думаете, было бы полезно преобразовать это в фабричные методы (но тогда нам придется беспокоиться о 250 отдельных файлах в нашем источнике ...)? Есть ли другая модель, которая более полезна? Просто иметь этот ОГРОМНЫЙ оператор переключения становится неуправляемым.

Любая помощь очень ценится. Заранее спасибо!

Answer 1

Вы можете создать Dictionary<DropDownType, DropDownDtoDelegate> с каждой записью, содержащей запись перечисления в качестве ключа и делегат для извлечения раскрывающихся данных в качестве значения. Это позволит вам хранить каждый метод, который возвращает выпадающий список, отдельно от оператора switch. Тогда у вас будет один метод для извлечения делегата, его выполнения и возврата данных раскрывающегося списка.

Answer 2

Есть несколько решений таких проблем.

1. Вы можете использовать словарь для отображения выпадающих списков на ваши данные.

2. Вы можете даже рассмотреть возможность перемещения этих картографических данных в базу данных. Количество данных может просто соответствовать этому решению.

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

Вот действительно хороший блог, посвященный смежным вопросам и предлагающий аналогичные решения.

Назад к основам - жизнь после If, For и Switch - как напоминание о структурах данных

Answer 3

Я бы использовал DynamicMethod для генерации кода во время выполнения для каждого элемента в перечислении. Это должно быть кэшировано в словаре и сгенерировано по требованию.

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

Я могу представить себе что-то вроде этого.

enum DropDownType
{
   [Configuration(Type = typeof(TableOne), DisplayNameProperty = "ColumnA", ValueProperty = "ColumnB")]
   T,

   [Configuration(Type = typeof(TableTwo), DisplayNameProperty = "ColumnC", ValueProperty = "ColumnD")]
   U
}

Если у вас есть значение enum, вы проверяете словарь для кэшированного метода, если его нет, вы генерируете его.

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

Answer 4

Одним из вариантов может быть использование отражения для обработки значения перечисления. Если у вас есть согласованный стандарт именования для всех участвующих классов, может быть способ динамически генерировать имя таблицы / коллекции для запроса и имя DTO для возврата. Для его работы потребуется немного «служебного» кода, но как только вы это сделаете, он потенциально может работать для всех различных таблиц.