14

私は新しいASP.NetMVCプロジェクトの開発の初期段階にあり、このプロジェクトを使用してDIに参加しています。構造マップを使用することは間違いありませんが、それは私が求めていることではありません。私が理解しようとしているのは、ソリューションを整理するための最善の方法です。単体テストプロジェクトとモデルの両方が、依存関係をマップするための構成ファイルを取得しますか、それともすべてを支配する1つのクラスがありますか？

また、私がこれに深く入り込む前に避けるべき初心者の罠はありますか？

どうもありがとう、すべて....。

更新 「ソリューションを整理する」と言うときは、ファイル/フォルダーの数などではなく、DIに関連するクラスを構造化する方法を指していることを追加する必要があります。特に、ブートストラッパーを管理する方法。私の側の言い回しが悪いと混乱を引き起こす可能性がある場所がわかります。

4

3 に答える 3

11

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

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

2番目の初心者の罠は、他の言語と比較して、すばらしいインテリセンス、コードナビゲーションツール、およびVisualStudioからのリファクタリングサポートの利点があることを忘れています。また、ファイルの置き忘れをはるかに簡単にするコンパイラもあります。「間違った」場所に何かを置いた場合、それは問題ありません。いつでもそれを見つけて、必要な場所にドラッグすることができます。

正直なところ、私は現在プロジェクトに取り組んでおり、特定のクラスがファイル構造のどこにあるのかさえわかりません。定義/宣言に移動は、私がよく使用するキーボードショートカットです。コードを操作しているのは私だけなので、これで問題ありません。プロジェクトに別の開発者を追加する必要がある場合は、おそらくクリーンアップします。

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

依存性注入がミックスに追加されているので、名前空間の爆発のみに関心があることをお勧めします。あなたができる最悪のことは、宣言とエイリアスを長く使ってブートストラッパーとファイルを乱雑にすることです。

ForRequestedType<Customer>

よりきれいです

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

また

ForRequestedType<KevDog.Models.Customer>

この問題を回避する別の方法は、名前を付けるときに明示的にすることです：Customer、CustomerViewModel、CustomerController、CustomerDataRow、CustomerView

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

今はDIも初めてなので、物事を非常にシンプルにし、101レベルのチュートリアルとドキュメントを反映する傾向があります。ビルド構成に基づいて動的インジェクションを開始する場合は、特定の状況でそれが必要であり、その理由が正確にわかっている場合にのみ使用してください。

私は通常、MVCアプリのデフォルトの構造も保持しています。すべてのチュートリアルとビデオの99％と同じ構造で、コードを作成する方が簡単です。

お役に立てれば。

于 2009-06-08T03:30:57.570 に答える
2

より良いTDDを奨励するため。2つのテストプロジェクトまたはnamespeacesX.Unit.TestsとX.Integrations.Testsがあります。

メインプロジェクトの「名前空間ディレクトリ」（/ Config）にDIコードがありますが、統合コードのテストでは、基本のフィクスチャまたはセットアップで必要な場合は、これらのレジストリを呼び出すか、オーバーライドすることがあります。

例えば

/Config/ServiceRegistry.cs /Config/RepositoryRegistry.cs /Config/Bootstrapper.cs

global.asaxで、Bootstrapper.Init（）を呼び出します。これにより、x.AddRegistry（new ServiceRegistry（））などが呼び出されます。

私の単体テストでは、統合テストでのみDIを使用する必要はありません。私のIntegrationTestsでは、たとえばNHibernateをデータベースまでテストしている場合、GetInstance（）をラップするだけのヘルパーメソッドを使用して、TestSetUpのRepositoryRegistryでSMを初期化できます。

どうしても必要になるまで、プロジェクト.Bootstraperと.Domainに分割しません...後でさらに移動する必要がある場合は、X、X.UnitTests、X.Integrationの3つのプロジェクト。私は、最初に削減するのが汚いと感じた数十のプロジェクトを抱えているというバックグラウンド/会社の強制から来ましたが、今はそうではありません。

于 2009-07-22T10:59:11.003 に答える
0

これが私自身のために同じ問題を解決する最初の試みですが、それは私の最初の試みなので、それがあなたのための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つは、このマネージャークラスをインスタンス化する他のコードが独自のStructureMapレジストリまたはアクションを提供できるようにするため、これらの具体的なインスタンスの代わりにモックを提供する自動テストの場合など、依存性注入自体を制御できます。依存関係。このソリューションはASP.NETMVCコンテキストに固有のものではなく、*。configファイルから構成情報を取得しないことを追加する必要があります。

于 2010-06-18T17:54:36.597 に答える