新しいアプリケーションを開始するとき、既存の依存関係フレームワークをそのまま使用して、潜在的な欠点をリスクにさらしますか?それとも、完全に適応可能な独自のフレームワークを作成することを選択しますか?それはなぜですか?
7 に答える
15
IMO、私たちの仕事はクライアントの問題を解決することであり、依存性注入 (またはロギング、ORM など) フレームワークを作成することではありません。私の意見では、適切なフレームワークが存在する場合は、常にそのフレームワークを使用する必要があります。
これに加えて、そのフレームワークがオープンソースである場合、考えられる欠点を修正できるため、使用しない言い訳はありません。
あまりにも多くの場合、私たちは目的の場所を見失うと思います。プログラマーとして、私たちは興味深い問題 (たとえば、依存性注入フレームワークの作成) に集中し、退屈な問題 (クライアント向けにさらに別の CRUD アプリケーションを作成する) を先延ばしにする傾向があります。:D
于 2009-01-27T20:16:33.910 に答える
5
現在出回っている DI フレームワークは (少なくとも .Net については) かなりしっかりしていると思います。
于 2009-01-27T20:16:34.097 に答える
2
最初は、DI フレームワークを実行するのは大したことではないように思えるかもしれませんが、Castle や Spring.NET などのフレームワークが提供するものを見れば、時間を費やすためのより良い方法を思いつくことができます。本当に特別なものが必要でない限り、利用可能なフレームワークの 1 つを採用し、他の人の作業を活用します。
于 2009-01-27T20:24:27.450 に答える
1
DI フレームワークは常に進化しており、コードのテストを容易にするなどの機能も追加されています。自分で書くと、プロジェクトが大きくなるとエラーが発生しやすくなり、おそらくより複雑になります。
DIが必要な場合はそれらを使用し、サポートの良いものを選択してください。
于 2009-01-27T22:38:51.860 に答える
1
もちろん、利用可能なソリューションの1つを使用します。最初は単純ですが、フル機能の DI フレームワークでは単純ではない機能 (さまざまなプロキシ機能など) がいくつかあります。多分あなたもいくつかのAOPが欲しいですか？
しかし、適切な DI フレームワークは、実際のコードの記述方法にほとんど影響を与えないはずなので、コードにとってはそれほど重要ではないと主張することができます。
しかし、それは誰が払っても問題になるかもしれません。あなたの状況では、ソースコードが利用可能なDIフレームワークを入手し、独自のソースを作成する代わりにそのソースを知るようになります。
于 2009-01-27T20:23:19.153 に答える
0
依存性注入ビットの周りにラッパーを書くことができるので、後で DI フレームワークを切り替えたい場合、ライブラリの依存性やコードの変更について心配する必要はありません。たとえば、container.Resolve を直接呼び出す代わりに、container.Resolve を呼び出すファクトリ クラスを作成し、ファクトリ クラスのみを呼び出します。
于 2009-01-28T06:41:58.297 に答える
0
オプション 3: 依存性注入を (まだ) 使用しないでください。
あなたは新しいプロジェクトを始めたばかりです。本当にDIフレームワークが必要ですか?
プロジェクトの開発を開始すると、問題のある依存関係がいくつか見られる場合があります。それらが出現し始めたら、既存の DI フレームワークを評価し、どれが適切かを判断できます。
DI フレームワークがまったく必要ないことに気付くかもしれません。
Martin Fowler でさえ次のように述べています。
制御の反転はフレームワークの一般的な機能ですが、それには代償が伴います。理解しにくい傾向があり、デバッグしようとすると問題が発生します。ですから、必要でない限り、私はそれを避けることを好みます。これは、それが悪いことだと言っているのではなく、より単純な代替手段よりも正当化する必要があると思うだけです.
http://martinfowler.com/articles/injection.html
もし私があなただったら、依存性注入なしでは絶対にやっていけなくなるまで、依存性注入の使用を避けるでしょう。
ほとんどの場合、YAGNIを思い出してください。
于 2009-01-27T22:20:04.690 に答える