タグ付けされた質問 「dependency-injection」

機能させる必要のあるソフトウェアコンポーネントの依存関係を動的に挿入することにより、コンポーネント間の結合を減らす設計パターン。

11
ファイルシステムに依存するコードの単体テスト
私は、ZIPファイルを指定した場合に必要なコンポーネントを作成しています。 ファイルを解凍します。 解凍したファイルから特定のdllを見つけます。 リフレクションを介してそのdllをロードし、その上でメソッドを呼び出します。 このコンポーネントを単体テストしたいのですが。 ファイルシステムを直接処理するコードを作成したくなります。 void DoIt() { Zip.Unzip(theZipFile, "C:\\foo\\Unzipped"); System.IO.File myDll = File.Open("C:\\foo\\Unzipped\\SuperSecret.bar"); myDll.InvokeSomeSpecialMethod(); } しかし、「ファイルシステム、データベース、ネットワークなどに依存する単体テストを記述しないでください」とよく言われます。 これをユニットテストに適した方法で書くとすると、次のようになると思います。 void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner) { string path = zipper.Unzip(theZipFile); IFakeFile file = fileSystem.Open(path); runner.Run(file); } わーい!今ではテスト可能です。DoItメソッドにテストダブル(モック)をフィードできます。しかし、どのようなコストで?これをテスト可能にするためだけに、3つの新しいインターフェースを定義する必要がありました。そして、正確には何をテストしていますか?私のDoIt関数がその依存関係と適切に相互作用することをテストしています。zipファイルが適切に解凍されたことなどはテストしません。 もう機能をテストしているような気がしません。クラスの相互作用をテストしているような感じです。 私の質問はこれです:ファイルシステムに依存する何かを単体テストする適切な方法は何ですか? 編集私は.NETを使用していますが、この概念はJavaまたはネイティブコードにも適用できます。

7
ServiceLocatorはアンチパターンですか?
最近、Service Locatorのアンチパターンに関するMark Seemannの記事を読みました。 著者は、ServiceLocatorがアンチパターンである2つの主な理由を指摘しています。 APIの使用に関する問題(これで問題 ありません)クラスがサービスロケーターを使用する場合、ほとんどの場合、クラスにはPARAMETERLESSコンストラクターが1つしかないため、依存関係を確認することは非常に困難です。ServiceLocatorとは対照的に、DIアプローチは、コンストラクターのパラメーターを介して依存関係を明示的に公開するため、IntelliSenseで依存関係を簡単に確認できます。 メンテナンスの問題(これは私を困惑させます) 次の例を考えます サービスロケーターアプローチを採用するクラス'MyType'があります。 public class MyType { public void MyMethod() { var dep1 = Locator.Resolve<IDep1>(); dep1.DoSomething(); } } 次に、クラス 'MyType'に別の依存関係を追加します public class MyType { public void MyMethod() { var dep1 = Locator.Resolve<IDep1>(); dep1.DoSomething(); // new dependency var dep2 = Locator.Resolve<IDep2>(); dep2.DoSomething(); } } そして、ここが私の誤解の始まりです。著者は言う: …

2
InvalidOperationException:タイプ 'Microsoft.AspNetCore.Http.IHttpContextAccessor'のサービスを解決できません
私は自分のasp.netコアRC1プロジェクトをRC2に変換し始めましたが、現在IHttpContextAccessor解決されていない問題に直面しました。 簡単にするために、私はVisual Studioテンプレートを使用して新しいASP.NET RC2プロジェクトを作成しましたASP.NET Core Web Application (.Net Framework)。テンプレートで作成されたHomeControllerのコンストラクタを追加したのではなく、 public HomeController(IHttpContextAccessor accessor) { } そして、アプリケーションを起動した後、次のエラーを受け取ります: InvalidOperationException: 'TestNewCore.Controllers.HomeController'をアクティブにしようとしているときに、タイプ 'Microsoft.AspNetCore.Http.IHttpContextAccessor'のサービスを解決できません。вMicrosoft.Extensions.Internal.ActivatorUtilities.GetService(IServiceProvider sp、Type type、Type requiredBy、Boolean isDefaultParameterRequired) 実際のアプリケーションIHttpContextAccessorでは、_contextAccessor.HttpContext.Authenticationとにアクセスするために、独自のサービスクラスで解決する必要があります_contextAccessor.HttpContext.User。EverethingはRC1で正常に動作します。それでは、RC2であるとどのように想定できますか?

4
フィールドインジェクションとは正確には何であり、それを回避する方法は?
フィールドインジェクションは推奨されないというSpring MVCおよびポートレットに関するいくつかの投稿を読みました。私が理解しているように、フィールドインジェクションとは、次の@AutowiredようなBeanをインジェクトすることです。 @Component public class MyComponent { @Autowired private Cart cart; } 私の研究中に、コンストラクター注入についても読みました: @Component public class MyComponent { private final Cart cart; @Autowired public MyComponent(Cart cart){ this.cart = cart; } } これらのタイプの注射の両方の長所と短所は何ですか? EDIT 1:この質問はの重複としてマークされているとおり、この質問私はそれをチェックします。質問にも回答にもコード例がないため、使用している注入タイプを推測して正しいかどうかはわかりません。

21
依存性注入はカプセル化を犠牲にする必要がありますか?
私が正しく理解している場合、依存性注入の一般的なメカニズムは、クラスのコンストラクターまたはクラスのパブリックプロパティ(メンバー)を介して注入することです。 これにより、注入される依存関係が明らかになり、カプセル化のOOP原則に違反します。 このトレードオフを特定することは正しいですか?この問題にどのように対処しますか? 以下の自分の質問に対する私の回答も参照してください。

4
Springで自己インスタンス化されたオブジェクトに依存関係を注入する方法は?
クラスがあるとしましょう: public class MyClass { @Autowired private AnotherBean anotherBean; } 次に、このクラスのオブジェクトを作成しました(または他のフレームワークがこのクラスのインスタンスを作成しました)。 MyClass obj = new MyClass(); 依存関係を注入することはまだ可能ですか?何かのようなもの: applicationContext.injectDependencies(obj); (Google Guiceには次のようなものがあると思います)

4
@Valueを使用したSpring式言語(SpEL):ドルとハッシュ($と#)
と${...}比較して、いつ使用するかについて少し混乱してい#{...}ます。Springのドキュメントではのみを使用していますが#{...}、を使用する例はたくさんあります${...}。さらに、SpELを使い始めたとき、私は使用するように指示され${...}、それは正常に機能しました。 混乱している人のために、私がそれをどのように使用するかの例は @Component public class ProxyConfiguration { @Value("${proxy.host}") private String host; @Value("${proxy.port}") private String port; : } そしていくつかのプロパティファイル: proxy.host=myproxy.host proxy.port=8000 私の質問は: 違いは何ですか、それとも同じですか? 1つのバージョンは廃止されているので、もう1つのバージョンを使用する必要がありますか?

4
Ioc / DI-アプリケーションのエントリポイントですべてのレイヤー/アセンブリを参照する必要があるのはなぜですか?
(この質問に関連して、EF4:遅延読み込みが有効になっているときにプロキシの作成を有効にする必要があるのはなぜですか?) 私はDIが初めてなので、我慢してください。コンテナーがすべての登録済みタイプのインスタンス化を担当していることを理解していますが、そのためには、ソリューション内のすべてのDLLへの参照とその参照が必要です。 DIコンテナーを使用していない場合は、MVC3アプリでEntityFrameworkライブラリを参照する必要はなく、DAL / Repoレイヤーを参照するビジネスレイヤーのみを参照します。 結局のところ、すべてのDLLがbinフォルダーに含まれていることを知っていますが、私の問題は、必要なすべてのファイルを含むWAPを公開できるように、VSの「参照の追加」を介して明示的に参照する必要があることです。

3
ContextLoaderListenerかどうか?
標準のSpring Webアプリケーション(Rooまたは「Spring MVC Project」テンプレートで作成)は、ContextLoaderListenerおよびでweb.xmlを作成しますDispatcherServlet。なぜ彼らはを使用してDispatcherServlet、完全な構成をロードするだけではないのですか? 私は、ContextLoaderListenerを使用してWebに関連しないものをロードする必要があり、DispatcherServletを使用してWebに関連するもの(コントローラーなど)をロードすることを理解しています。この結果、2つのコンテキスト(親コンテキストと子コンテキスト)が生成されます。 バックグラウンド: 私はこの標準的な方法で数年間それをしていました。 <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath*:META-INF/spring/applicationContext*.xml</param-value> </context-param> <!-- Creates the Spring Container shared by all Servlets and Filters --> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!-- Handles Spring requests --> <servlet> <servlet-name>roo</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>WEB-INF/spring/webmvc-config.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> これにより、2つのコンテキストとそれらの間の依存関係で問題が発生することがよくありました。以前は常に解決策を見つけることができました。これにより、ソフトウェアの構造/アーキテクチャが常に改善されると強く感じています。しかし今、私は両方の状況の出来事で問題に直面しています。 -ただし、これにより、この2つのコンテキストパターンを再考し、私は自分自身に問いかけます。なぜ、この問題に自分を持ち込む必要があるのか​​、すべてのSpring構成ファイルを1つにロードしDispatcherServletてContextLoaderListener完全に削除しないのはなぜですか。(まだ、異なる構成ファイルを使用しますが、コンテキストは1つだけです。) 削除しない理由はありますContextLoaderListenerか?

4
javax.inject.Namedアノテーションは何に使用されることになっているのですか?
私はjavax.injectパッケージを理解しようとしていますが、javax.inject.Named注釈が何に使用されることになっているのか明確ではありません。Javadocは、その背後にある考え方を説明していません。 Javadocはhttp://download.oracle.com/javaee/6/api/javax/inject/Named.htmlにあります 私はSpring 3.0を使用していくつかのサンプルプログラムを記述しています@Namedが、Beanを配置することでBeanファクトリに追加されているようですが、Javadocの記述は非常に軽いため、標準の動作なのかSpring固有の動作なのかわかりません。 私の質問は: 違いは何ですか@Namedと@Qualifier ランタイムシステムに、クラスを他のクラスに注入できるようにするには、どのようなアノテーションを付ければよいですか?@Component春に相当? Update 1についての素晴らしい説明が@Namedあります。また、https: //dzone.com/articles/java-ee6-cdi-named-components @Qualifierに関するニースの記事には、以下のコメントへのリンクについて@xmedekoに感謝しています。@Named@Qualifier


8
Jersey 2.0での依存性注入
以前のJersey 1.xの知識がない状態でゼロから始めて、私はJersey 2.0プロジェクトで依存関係注入をセットアップする方法を理解するのに苦労しています。 また、HK2がJersey 2.0で利用可能であることも理解していますが、Jersey 2.0の統合に役立つドキュメントを見つけることができないようです。 @ManagedBean @Path("myresource") public class MyResource { @Inject MyService myService; /** * Method handling HTTP GET requests. The returned object will be sent * to the client as "text/plain" media type. * * @return String that will be returned as a text/plain response. */ @GET …

4
.NET Core DI、コンストラクターにパラメーターを渡す方法
次のサービスコンストラクターを持つ public class Service : IService { public Service(IOtherService service1, IAnotherOne service2, string arg) { } } .NET CoreIOCメカニズムを使用してパラメーターを渡すための選択肢は何ですか _serviceCollection.AddSingleton<IOtherService , OtherService>(); _serviceCollection.AddSingleton<IAnotherOne , AnotherOne>(); _serviceCollection.AddSingleton<IService>(x=>new Service( _serviceCollection.BuildServiceProvider().GetService<IOtherService>(), _serviceCollection.BuildServiceProvider().GetService<IAnotherOne >(), "" )); 他に方法はありますか?

16
依存性注入コンテナの利点は何ですか?
依存性注入自体の利点を理解しています。たとえば、Springを例にとってみましょう。また、AOPやさまざまな種類のヘルパーなど、他のSpring機能の利点についても理解しています。次のようなXML構成の利点は何でしょうか。 <bean id="Mary" class="foo.bar.Female"> <property name="age" value="23"/> </bean> <bean id="John" class="foo.bar.Male"> <property name="girlfriend" ref="Mary"/> </bean> 次のようなプレーンな古いJavaコードと比較して: Female mary = new Female(); mary.setAge(23); Male john = new Male(); john.setGirlfriend(mary); これはデバッグがより簡単で、コンパイル時間をチェックし、Javaだけを知っている人なら誰でも理解できます。それでは、依存性注入フレームワークの主な目的は何ですか?(またはその利点を示すコードの一部) 更新:の 場合 IService myService;// ... public void doSomething() { myService.fetchData(); } IoCフレームワークは、複数ある場合に、注入するmyServiceの実装をどのように推測できますか?特定のインターフェイスの実装が1つしかなく、IoCコンテナーにそれを使用するように自動的に決定させると、2番目の実装が表示された後に壊れます。また、インターフェースの実装が意図的に1つしかない場合は、それを注入する必要はありません。 IoCのメリットを示す小さな構成を見るのは本当に興味深いでしょう。私はしばらくSpringを使用しており、そのような例を提供することはできません。また、休止状態、dwr、および私が使用するその他のフレームワークの利点を示す1行を表示できます。 更新2: IoC構成は再コンパイルせずに変更できることを理解しています。本当にいいアイデアですか?再コンパイルせずにDB資格情報を変更したい場合は理解できます-彼は開発者ではない可能性があります。実際に、開発者以外の誰かがIoC構成を変更する頻度はどれくらいですか?開発者にとって、構成を変更する代わりにその特定のクラスを再コンパイルする努力はないと思います。そして、非開発者にとっては、おそらく彼の人生をより簡単にし、いくつかのより単純な設定ファイルを提供したいと思うでしょう。 更新3: インターフェースとその具体的な実装間のマッピングの外部構成 それを外部のものにすることで何が良いのですか?すべてのコードを外部にする必要はありませんが、ClassName.java.txtファイルに配置して、オンザフライで手動で読み取り、コンパイルすることはできますが、再コンパイルは不要です。コンパイルを避けるべきなのはなぜですか? 手続き型コードではなく宣言的にマッピングを提供するため、コーディング時間を節約できます。 ときどき宣言的アプローチが時間を節約することを理解しています。たとえば、BeanプロパティとDB列の間のマッピングを一度だけ宣言し、HSQLに基づいてSQLをロード、保存、構築するときにhibernateがこのマッピングを使用します。これが宣言的なアプローチが機能する場所です。Spring(私の例では)の場合、宣言はより多くの行を持ち、対応するコードと同じ表現力を持っていました。そのような宣言がコードより短い場合の例があれば、私はそれを見たいです。 制御の原則の反転により、実際の実装を偽の実装に置き換えることができるため(SQLデータベースをメモリ内の実装に置き換えるなど)、ユニットテストが容易になります。 …

7
Angularjsはベストプラクティスを縮小します
私はhttp://www.alexrothenberg.com/2013/02/11/the-magic-behind-angularjs-dependency-injection.htmlを読んでい ますが、javascriptを縮小すると、angularjs依存性注入に問題があることがわかりました。の代わりに var MyController = function($scope, $http) { $http.get('https://api.github.com/repos/angular/angular.js/commits') .then(function(response) { $scope.commits = response.data }) } あなたは使うべきです var MyController = ['$scope', '$http', function($scope, $http) { $http.get('https://api.github.com/repos/angular/angular.js/commits') .then(function(response) { $scope.commits = response.data }) }] 全体的に見て、2番目のスニペットは古いバージョンのangularjs用のものだと思いましたが.... 常に注入方法(2番目)を使用する必要がありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.