3

経験の浅い開発者がいるプロジェクトで使用するので、Spring.NETなどの複雑なフレームワークはオプションではありません。私は考えていました:

  1. 注入する
  2. キャッスルウィンザー
  3. StructureMap

柔軟性を失うことなく、適度な学習曲線を示すのはどれですか?

そして別の質問-構成を置く正しい場所はどこですか?3層ASP.NETアプリケーションのカーネル/構成(MVCではありません!!!すべての例でMVCを使用しています:))

4

11 に答える 11

4

DI の適切な使用に関する優れた点は、どの DI コンテナーを使用するかの決定を最後の責任ある瞬間まで延期できることです。アプリケーション アーキテクチャの用語では、これは、すべての依存関係を結び付ける、いわゆるコンポジション ルートに対応します。多くの場合、これはアプリケーションのエントリ ポイントです。

コンポジション ルートとは別に、特定の DI コンテナーをまったく参照せずに、アプリケーション全体を作成できます。よく知られているパターンと原則に従うだけです。

DI コンテナーの選択に関しては、次の .NET 用 DI コンテナーを認識しています。

個人的には、これまでのところウィンザー城に満足していますが、これらすべてのコンテナについてはまだ十分な経験を積んでいません.

于 2010-02-04T08:45:25.893 に答える
2

ASP.NET (MVC ではない) Ninject サンプルを次に示します。

http://davidhayden.com/blog/dave/archive/2008/06/20/NinjectDependencyInjectionASPNETWebPagesSample.aspx

于 2010-02-04T09:50:19.723 に答える
0

http://funq.codeplex.com/を見てください。まず、windsor や他のリフレクション ベースのコンテナーと比較して非常に高速です。次に、非常に柔軟ですが、非常に読みやすい構成になっています。とにかく長くかかるLamba式)

于 2010-02-04T10:17:37.220 に答える
0

管理された拡張性フレームワークを使用します。これは .NET 4.0 フレームワーク (現在はリリース候補版) の一部であり、 System.ComponentModel.Composition名前空間で見つけることができます。codeplex サイトは、現在でもドキュメントの最良のソースです。

MEF は「依存関係の挿入」よりも「拡張性」に重点を置いていますが、これを実現するために依存関係の挿入を使用しています。たとえば、Visual Studio 2010 コード エディターは MEF を使用して拡張性を有効にします。

私たちはこれを DI フレームワークとして使用しており、まだ問題に遭遇していません (ただし、まだコアの一部ではない動的インスタンス化サンプルが必要でした)。

于 2010-02-26T11:44:04.677 に答える
0

DI フレームワークにまだ精通している場合は、Simple Injectorを使用します。

非常にシンプルな API を備えているため、すぐに使い始めることができます。シンプルですが、多くの高度な構成シナリオを有効にします。移行を念頭に置いて設計されたライブラリです。つまり、別のフレームワークへの切り替えはかなり簡単です。この点を証明するために、プロジェクトの wiki に移行ガイドがあります。

于 2010-03-05T14:54:43.823 に答える
0

Autofacは私が選んだコンテナです。最大限の柔軟性のためにラムダ式を介して登録できます (リンクにはいくつかの良い例があります)。

また、Silverlight 互換バージョンもあります。他のコンテナがそうであるかどうかはわかりません。

配置に関しては、コンテナーはアプリケーションの起動時にビルドする必要があります。ASP.NET アプリケーションの場合、これは Global.Application_Start メソッドにあります。

Autofac には、起動時に作成したコンテナーを使用してページ インスタンスを挿入するASP.NET 統合があります。

于 2010-02-04T02:06:16.283 に答える
0

優れた製品である Ninject に加えて、私がよく知っている 2 つのオプションがあります。

  1. マイクロソフトのユニティ。一部の Alt.NET 関係者は、少し大きくて複雑な面があると考えています。Prism の一部として数か月間使用しており (Prism は Unity を使用する必要はありません。スタンドアロンで使用できます)、シンプルでわかりやすいことがわかりました。
  2. ストラクチャマップ. また、StructureMap の学習曲線は非常に緩やかで、立ち上がりも速いことがわかりました。

お役に立てれば。

于 2010-02-03T18:30:38.490 に答える
0

spring.net を拒否するには性急すぎると思います。Spring は非常に柔軟な学習曲線を提供するため、最初は「必要なものを取得する」というアプローチになります。
最も単純な IoC コンテナーから始めて、後で aop、トランザクション、単体テストなど、必要なものに移行すると、複雑さが徐々に増していきます。

これは、Spring を使用する私の最後の 2 つの仕事での一番のセールス ポイントでした。追加のポイントは次のとおりです。

  • その API を使用したり、アーキテクチャを曲げたりする必要はありません。繰り返しますが、これにより、自分のペースでその機能を適応させることができます。
  • 非常に広範なドキュメント。

プロジェクトが成熟すると、開発者も成熟するため、春は最後に便利になります...(私の意見では、最初は無料です)

于 2010-02-03T18:23:00.117 に答える
0

私は ninject を使用しており、新しい開発者が簡単にそれに慣れることができました。

于 2010-02-03T18:18:20.567 に答える
0

手で配線することから始めることを検討してください: http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversionを参照してください。経験の浅い開発者に、IOC/DI の基本についてのより良い洞察を提供します。

于 2010-02-03T18:21:54.613 に答える
-2

StructureMap は非常に便利で直感的に使用できると思います。Ninject を少し使ってみたところ、あまり便利ではありませんでしたが、YMMV でした。また、IOC の実際の実装とアプリケーションの間の仲介として共通サービス ロケーターを使用することをお勧めします。後で IOC/DI コンテナーを切り替えたい場合、これはそれほど苦痛ではありません。StructureMap と Castle windsor 用のアダプターがあります。また、このブログによると Ninject 2 用のアダプターもあるとグーグルで考えています。

于 2010-02-03T18:39:41.963 に答える