私は自分より先に進んだと思います。コードは何かを行いますが、構成はコードに何をどのように行うかを単に伝えるため、コードを構成に置き換えることはできません(構成自体にコードが含まれている場合を除き、パラドックスがあります)。コードに構成可能性を適用する場合は、まずコードをより一般的/汎用的にする必要があります (あなたのswitch
ステートメントは、現在は一般的ではないことを示しています)。これを行うための私のアプローチは、私の元の回答(以下)で説明されています。それ自体では構成可能性を提供しませんが、そうすることができます (私はかなり簡単にそれを行いました)。コードは元の質問に基づいているため、目を再調整して正しく読み取ってください。
私が過去に選択したオプションは、ファクトリを使用することでした (Singleton に格納されるか、IoC コンテナーの形式でコード サンプルを所有する関数に渡されます)。
私のアプローチの非常に高レベルの実装は、基本的に、型がいつ役立つかを示すプロパティを含むカスタム属性を定義することです。何かのようなもの:
public class DbOperationAttribute : Attribute
{
public string Operation { get; set; }
}
また、コードを実行するために必要な API を提供するための共通インターフェイス。何かのようなもの:
public interface IDoSomethingSpecial
{
bool Execute(SomeExecutionContext context);
}
次に、特定のクラスを属性で装飾し、インターフェースを実装して、それらが各アクションに適していることを示します。
[DbOperation(Operation = "Read")]
public class DBReadOperation : IDoSomethingUseful
{
// Our implementation of the `IDoSomethingUseful` interface
public bool Execute(SomeExecutionContext context)
{
// Do something useful in here
}
}
プログラムのある時点で、どのタイプがどのアクションに適しているかを発見できる必要があります。これはリフレクションを使用して行いますが、構成を使用しても同じように簡単に行うことができます (属性のポイントが無効になります)。いくつかの IoC コンテナーは同様の発見可能性属性を提供しますが、他の誰かのものを使用すると、(通常は) 独自の方法で処理を行うことになります。
どのタイプがどのアクションに適しているかがわかったら、次のようなものを使用できます。
IDoSomethingUseful someAction = myCollectionOfUsefulThings(requesttype);
someAction.Execute(someInstanceOfOurContextType);
App.Config
この設計に基づいて、 /を使用しWeb.Config
て構成を保存することに傾倒します。とにかく、それは通常そこにあります。あなたの目的のためにそれを使うこともできます。