依存性注入を使用してASP.Net MVCソリューションを構成する最善の方法は何ですか？

Question

私は新しいASP.Net MVCプロジェクトの開発の初期段階ですが、このプロジェクトを使用してDIに取り掛かります。私は構造マップを使うつもりだと確信していますが、それは私が求めていることではありません。私が把握しようとしているのは、私のソリューションをどのように整理するのが最善かです。単体テストプロジェクトとモデルの両方は、依存関係をマッピングするための構成ファイルを取得するのか、それともすべてを統治するクラスがありますか？

また、これに入る前に、初心者のトラップがありますか？

多くのおかげで、すべての.....

更新 は、私は「解決策を整理する」と言うとき、私は、ファイル/フォルダの数などに言及していないよということを付け加えなければなりませんむしろDIに関わるクラスをどのように構造化するのかということです。特に、ブートストラップをどのように管理するか。自分の貧弱な言い回しが混乱の原因になることがわかります。

Answer 1

より良いTDDを奨励します。 2つのテストプロジェクトと名前ペイントがあります。X.Unit.Tests & X.Integrations.Tests。

"名前空間ディレクトリ"（/ Config）のメインプロジェクトに私のDIコードがありますが、私の統合コードテストでは、それらのレジストリを呼び出すか、ベースフィクスチャまたはセットアップで必要ならば上書きするかもしれません。

など。

/Config/ServiceRegistry.cs /Config/RepositoryRegistry.cs /Config/Bootstrapper.csのGlobal.asaxで

私はBootstrapper.Initを（呼び出し）と、このx.AddRegistryを呼び出します（新しいてServiceRegistry（ ）） 等々。あなただけの統合テストでDIを使用してする必要がいけない私のユニットテストで

。たとえば、私のIntegrationTests。私がデータベースにNHibernateをテストしている場合、私はGetSet（GetInstance（）をラップするヘルパーメソッドを使ってTestSetUpのRepositoryRegistryでSMを初期化するかもしれません）。

私が絶対にする必要があるまで、私はプロジェクトに.Bootstraperと.Domainを分割しません。後でもっと移動する必要がある場合は、3つのプロジェクト、X、X.UnitTests、X.Integration。私はバックグラウンド/企業の執行から数十のプロジェクトを抱えていましたが、それは最初の削減を感じましたが、今はそうではありません。私は急速に成長し、必要に応じて後でソリューション構造を再編成します。ここで

Answer 2

あなたがプロジェクトに取り組んでいる唯一の人なら、私はにまず何を意味するのですか。直感的ではないディレクトリやプロジェクト構造をあなたに課すことよりも悪いことはありません。 BaseControllerクラスは\ Core \フォルダまたは\ Controller \フォルダにありますか？個人的にはコントローラを見ていますが、一部の人は\ Core \ or \ Basesにあるべきだと誓っています。

最初の初心者トラップは、コードを間違った方法で整理できると考えています。これは、プロジェクトの成功を反映しています。私は、30のファイルが1つのフォルダにあり、他のプロジェクトでは30のファイルに対して20のフォルダがあるプロジェクトを見てきました。

2番目の初心者のトラップは、他の言語に比べて、素晴らしいインテリセンス、コードナビゲーションツール、およびVisual Studioのリファクタリングサポートの利点を忘れています。また、ファイルを誤って配置することにより、苦痛を軽減するコンパイラもあります。あなたが "間違った"場所に何かを置くなら、それは大丈夫です、あなたはいつでもそれを見つけて、それが必要な場所にドラッグすることができます。

私は正直言って私は今、プロジェクトに取り組んでいます。私は、特定のクラスが私のファイル構造にどこにあるのかもわかりません。 Go To Definition/Declarationはキーボードショートカットです。コードで作業しているのは私だけですので、これは問題ありません。私がプロジェクトに別の開発者を追加しなければならないとすれば、おそらく私は物事をきれいにするだろう。

個人的には、実装するタイプのInterfacesを同じフォルダ内に配置する傾向があります。 IPaymentGatewayは、AuthorizeNetGatewayとPaypalGatewayと同じフォルダにあります。ソリューションエクスプローラのサイドバーで、そのフォルダ内のすべてのファイルを一度に表示できない場合は、すべてのゲートウェイファイルを\ Gateway \フォルダに移動します。

依存関係注入をミックスに追加すると、名前空間の爆発だけに関係することをお勧めします。最悪のことは、宣言とエイリアスを使用してブートストラップとファイルを長く混乱させることです。

ForRequestedType<Customer> 

はクリーナーより

using KevDog.Models 
using Customer=KevDog.Models.Customer 

または

ForRequestedType<KevDog.Models.Customer> 

この問題を回避するための別の方法明示することとしたとき、あなたの命名の事：顧客、CustomerViewModel、CustomerController、CustomerDataRow、CustomerView

TDDの場合、ほとんどの場合、管理するブートストラップが2つ必要ですあなたの具体的なタイプ。 AuthorizeNetGateway：IPaymentGateway、むしろStubGateway：IPaymentGatewayを使用するあなたのユニットテストを実際にしたくない。

は今、私はので、私は物事が非常にシンプルにする傾向があり、101レベルのチュートリアルとマニュアルをミラーDIでも新たなんです。ビルド構成に基づいて動的注入を行うには、特定の状況で必要な場合にのみ使用し、その理由を正確に把握する必要があります。

私は通常、同様MVCアプリケーションのデフォルトの構造を維持します。すべてのチュートリアルやビデオの99％と同じ構造でコードを作成するほうが簡単です。

これが役に立ちます。

Answer 3

は自分のために同じ問題を解決するために私の最初の試みであるが、それは私の最初の試みであるので、私は人々が上でコメントや同じくらい私はそれがための1つの可能な解決策となる恐れがありますことを望んでいるだろうとして、それを批判するかもしれないことを望んでいるだろうあなた：

public VatManager() 
: this(new VatManagerRegistry()) { } 

public VatManager(Registry registry) 
: this(new Action<IInitializationExpression>(x => { x.AddRegistry(registry); })) 
    { 
    } 

public VatManager(Action<IInitializationExpression> action) 
    { 
    ObjectFactory.Initialize(action); 
    data = ObjectFactory.GetInstance<IVatManagerData>(); 
    } 

私は3つのコンストラクタのオーバーロードを持つ - パラメータなしのデフォルトコンストラクタは、生産コンテキストで使用するために作成する必要があり、具体的なのStructureMapレジストリの知識を持っています。他の2つは、このマネージャクラスをインスタンス化する他のコードが、それらの具体的なインスタンスの代わりにモックを提供する自動テストの場合など、依存関係の注入自体を制御できるように、独自のStructureLapレジストリまたはアクションを提供することを許可します依存関係。 このソリューションはASP.NET MVCコンテキストに特有ではなく、*。configファイルから構成情報を取得しないことを追加する必要があります。