Хорошие форматы для хранения информации о конфигурации, такой как имена хранимых процедур

Question

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

switch(requesttype)
{    
  case "GetEmployees":
         switch (crud_type)
                 {
                    case "read":
                          Execute Stored Procedure 'A'
                    break;
                 }
   break;      
}

Мы ищем способы удалить приведенный выше код (который находится внутри файлов классов) в какой-либо форме файла конфигурации

1. Мы ищем формат хранения файлов, который можно очень быстро извлечь (прочитать, проанализировать и т. Д.) И сохранить (записать, изменить и т. Д.)

2. Мы могли бы реализовать защитуслой над ним

3. Достигните этого без особых хлопот и серьезных изменений в существующем коде.

Answer 1

Я думаю, что я опередил себя.Вы не можете заменить код на конфигурацию, потому что код будет делать что-то, в то время как конфигурация просто скажет коду, что или как что-то делать (если только сама конфигурация не содержит кода, в этом случае у вас возникает парадокс).Если вы хотите применить конфигурируемость к своему коду, вам сначала нужно сделать его более общим / общим (ваши операторы switch указывают, что он не общий сейчас).Мой подход к этому описан в моем первоначальном ответе (ниже).Сам по себе он не обеспечивает конфигурируемость, но может быть сделан для этого (я сделал это довольно просто).Код основан на вашем исходном вопросе, поэтому, пожалуйста, отрегулируйте ваши глаза, чтобы правильно его прочитать.

---

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

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

public class DbOperationAttribute : Attribute
{
    public string Operation { get; set; }
}

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

[DbOperation(Operation = "Read")]
public class DBReadOperation : IDoSomethingUseful
{
    // Our implementation of the `IDoSomethingUseful` interface
    public bool Execute(SomeExecutionContext context)
    {
        // Do something useful in here
    }
}

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

Как только вы обнаружите, какие типы подходят для каких действий, вы можете использовать что-то вроде:

IDoSomethingUseful someAction = myCollectionOfUsefulThings(requesttype);
someAction.Execute(someInstanceOfOurContextType);

Основываясь на этом дизайне, я бы склонялся к использованию App.Config / Web.Config для хранения вашей конфигурации.Это вообще будет там так или иначе;может также использовать его для ваших целей.