0

複数のプロジェクトを使用して、DI 用の IoC フレームワークを組み込んだ .NET (C#) 用の空のソリューション スタックを作成した人はいますか? 私は何ヶ月もの間、次のような優れた再利用可能なスタックを作成するのに苦労してきました:

  1. MVC UI Web アプリ
  2. 空の BLL プロジェクト (後で実際のエンティティを追加します)
  3. 空の DAL プロジェクト (後で実際の daab クラスを追加します)
  4. 参照/検索データ層
  5. IoC フレームワークを含む
  6. エンティティ レイヤーを介して DAL に到達するか、すべてのインターフェイスを介して層を参照/検索することができるホーム コントローラーでの DI の使用例
  7. UI レイヤーで具象クラスのハード参照を設定してはなりません

私はこれを数回試みましたが、常に #6 でハングアップし、スタックの構造に基本的なものが欠けています。誰かがこれを行うことができ、それがどのように構造化されているかを示すサンプルソリューションを持っていますか? 一日中スタックを作成して IoC フレームワークを追加することはできますが、UI レイヤーに具体的な参照が追加されないように構造化することは完全に失敗します。オブジェクトのインターフェイス/具体的な解決は、他にどのように行うことができますか?

確かにあなたの学者の中にはこれをつぼみに挟んでいる人もいます。この啓発の一部を私と共有してください:-)

ps - Mark Seeman の本を 2 回以上読んだことがあります。Composition Root の概念は理解していますが、NTier ソリューションで使用されているのを見たことがなく、理論をうまく実装できていません。

私が探しているのは、出発点として使用できる複数のプロジェクトの具体化されたソリューション スタックです。コンポジションルートをうまく実装し、言う代わりに実行することでSOLIDの原則を教えるために使用できるもの。すべてを実現するソリューションです。この質問を参照してください。

4

2 に答える 2

1

My Shuttle Wiki FOSS には、目的の要素がいくつかあります。

http://shuttlewiki.codeplex.com/

すべての懸念事項が独自のプロジェクト/アセンブリにあるわけではありませんが、関連するアセンブリを別の場所で実際に使用する場合を除き、それらをばらばらにする努力は無駄であることがわかりました。そうは言っても、懸念事項を切り離すように注意が払われているため、それらを分割することは依然として非常に簡単です。

コメントの一部をスキャンしました。私の意見では、他の開発者が特定のクラスを使用するのを防止または保護するために、プロジェクトの構造や手法を使用するべきではありません。ジュニア開発者は、ある段階でコツを学ぶ必要があり、簡単なコード ウォークスルーでは、達成しようとしているものと一致しないコーディングを取り上げることがあります。

于 2012-05-16T04:18:48.427 に答える