Springを理解しようとしています。私はそれについて読んで、いくつかのチュートリアルを行った。私はIoCのパラダイムと、DIがSpringで実装されているという事実を得ています。Springを使用しない場合の問題点
私の質問はこれです：あなたは春を使わないことで何を失いますか？私はこれが大きな疑問で、幾分主観的だと理解しています。しかし、もしあなたが点点をいくつか書いたり、Springが使用されなかった場合に起こりうる問題の例を挙げることができれば、それは私と他の多くの人々に役立つと思います。
実際には問題ありません。しかし、コードを書くことを始めると、Springのような自家製のフレームワークになります。 Springを使って得られることは、フレームワークが（自分のものよりも）より一般的であり、多くの異なるプロジェクトでそれを使うことができるということです。そして、最も重要な点は、Springがそれを使用する多くのユーザーとの間でよくテストされていることです。
もちろん、Springだけでなく他のフレームワークも試すことができます。そこにたくさんあります...
あなたはあなた自身でそれをすべてコード化しなければならないということです。私は春（まだ）について多くを知らないが、春を使用すると、2つの編集点を必要とするのに対し、でも、コンストラクタ・インジェクションの基本的な行為は、多くのコードが必要になります。
設定では：
<sectionGroup name="spring">
<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
<section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>
<spring>
<context>
<resource uri="config://spring/objects"/>
</context>
<objects xmlns="http://www.springframework.net">
<object name="mediaLibrary" type="AlbumLibraryWPF.AlbumLibrary, AlbumLibrary"/>
</objects>
</spring>
でコード：
IApplicationContext ctx = ContextRegistry.GetContext();
library = (Library)ctx.GetObject("mediaLibrary");
あなたはどちらかといえば：DIフレームワークを自分で書くか、ソリューションを構築するのに集中しますか？
Springは単なる別のIoCツール（DAO関連のもの、便利なMVCサポート、テストツールなど）をはるかに超えています。私の意見では、それは徐々にJavaの "風味"の一種に成長しました。しかしそれはポイントではありません:) IoC/DIについて言えば、それを使用しないで緩めるのは、アプリケーションでゆるやかなカップリングを得るための最も簡単な方法です。これは再利用性に関連しています。明らかに、ほとんどの人は、私の経験上、それほど頻繁に起こらない別のプロジェクトのコンポーネントの再利用性について考える傾向があります。あなたのコードをユニットテストする必要がある場合、再利用性の最大の利点が現れます。 DI/IoCを使用してインターフェイスとを介してプログラミングすることは単体テストを非常に簡単にするので、単体テストに嫌な人でもそれを愛するようになります。
UT問題の緩やかなカップリングと利点は、あなたが失うことの1つです。
IoCはほとんどのアプリケーションが成長を始め、モジュール化/ルーズカップリングを設計していないと、意味のない境界がなくても大きな相互接続クラスになります。
Springやその他のIoC/DIフレームワークでは、最初からモジュール化について考えることができます。これは大きなコードですが、モジュール化された/疎結合のコードを使用すると、単体テストを行う場合にはユニット化テストがより多く行われます。
私はDAOを書きたい場合は、私はフロントまでそのインタフェースを定義することができます
interface IPersonDao {
List<Person> getPersonsByTeam(String teamName);
}
、その後、私はちょうどどこでも春は「適用されているのsrcでから、このインタフェースの実装のために呼び出すことができます"私はサービス層でそれを必要とします
class MyService {
@Autowired
IPersonDao svc;
}
やテストクラスで：
class TestPersonDao {
@Autowired
IPersonDao svc;
@Test
void testGetPersons(){
List<Person> persons = svc.getPersonsByTeam("billing");
Assert.assertDataSet(persons, "billing.xml");
}
}
また、私のDAO実装は、ダオ契約をいじりせずにデータアクセスの複雑さを隠すことができます。私はHibernateセッションやパーシスタンス・マネージャーを必要とする場合、私はちょうどそれを宣言します。クラスの
class JpaPersonDao implements IPersonDao {
@PersistenceContext
EntityManager em;
List<Person> getPersonsByTeam(String tm) {
em.createQuery("...");
}
}
コンポーネント化は、共同で豆を配線するために、レジストリが必要です。これは手で開発することができますが、これを行うDIフレームワークは既に存在します。さらに、Springは、例外翻訳、アスペクト・プログラミング、MVCフレームワーク、ポートレット・フレームワーク、hibernate、jpaおよび/または他のdbスタックとの統合のような他のものもたくさんあります。もちろん、Spring IoCのものとうまく統合できます。
スプリングはDIフレームワークをはるかに上回ります。そこにはあなたのためのプログラミングが簡単になりますエリアがたくさん：
これらはほんの一部の例です - より多くのがあります。上記のいずれかを使用する必要はありませんが、成熟した、よく設計されたフレームワークのすべての部分があり、一般的にそれらは簡単になります。
春のコアは、もちろん依存性注入です。 DIフレームワークを使用する利点は、小規模なプロジェクトでは明らかではないかもしれませんが、大規模で複雑なものではそれ以上に明らかです。 Martin FowlerはInversion of Controlを非常にはっきりと説明しています。もちろん、他の選択肢（Guiceなど）もありますが、Springは現在業界標準です。
私は、人々が（SpringやGoogle Guiceのような）依存性注入フレームワークを使用する理由を書き上げました。ほとんどのチュートリアルではこれを無視していますが、IMHOは最も重要なことです。
あなたが持っている問題と、これらのパターン/フレームワークが解決する問題を理解すれば、良いソフトウェアと優れたアーキテクチャ上の選択肢を作ることができます。ここではそれについて
読むには：http://www.redcode.nl/blog/2010/01/dependency-injection-dissection
簡単に言えば、あなたはクリーンでテスト可能なコードを書くための依存性注入を適用します。また、代わりに、呼び出し元が呼び出し先ではなく、使用するインプリメンテーション（インジェクション）を知っている設計を実現します（これは「ハリウッドの原則」として有名です）。今では、SpringやGuiceのようなDIフレームワークを使わないと、工場を使って依存性注入を試みます。しかし工場では、テスト中に定型コードと不安なクリーンアップのコストがかかります。また、StrutsやHibernateなどのさまざまな層に属するフレームワークとの容易な統合が可能な、これらのフレームワークでは他の強みもあります。
また、Ruby on Railsの背景からSpringを学習しています。私はSpringが解決する問題に感心しています。 そして、Microsoftの世界は何ですか？彼らはそのような枠組みも持っていますか？ NHibernateはありますが、公式のNSpringやそのような計画はありますか？ –
Spring.NETと呼ばれています。多くの.NET IoCフレームワークが利用可能です。 – kgiannakakis