SpringComparison
How does Guice compare to Spring et al?
The Spring Framework, created by Rod Johnson, blazed the Java dependency injection trail. If not the first dependency injection framework, you can certainly credit Spring with pioneering much of what we know about dependency injection and bringing it into the mainstream. Guice might not exist (at least not this early) if not for Spring's example.
どうやってGuiceをSpringやその他のDIを比べるのでしょう？
Rod Johnsonによって作られたSpringFrameworkは、Dependency Injectionを大流行させました。まして、最初のDependencyInjectionフレームワークであり、SpringがDependencyInjectionに関する知識の多くを開拓して、それをメインストリームに運び込んだことは確かに称賛することができます。 Springの例がなければ、Guiceは存在しないかもしれません(少なくともこれほど早くありませんでした)。
Guice and Spring don't compete directly. While Spring is a comprehensive stack, Guice focuses on dependency injection. Even so, the first question most people ask is, "how does Guice compare to Spring?" Rather than repeat the same spiel N times, we figured it best to answer the inevitable question once.
GuiceとSpringは、直接比較することは出来ません。その上、Springは、包括的なスタックです。GuiceはDependecyInjectionに焦点を合わせています。とは言うものの、ほとんどの人が疑問に思うのは同じ宣伝文句を何回繰り返すかということよりも、むしろ"どうやってGuiceをSpringとくらべるの？"ということです。その避けられない質問への最適な回答を考えてみましょう。
Let us start by saying, the Guice team has a great deal of respect for the Spring developers, community, and their overall attitude. We're more than willing to work together in any capacity. We even gave a few core Spring developers a sneak peek at Guice six months before the 1.0 release, and they've had access to the source code repository ever since.
言い習わしから始めましょう。GuiceチームはSpring開発者、共同体、および彼らの総合的な態度に対する多くの敬意を持っています。どんな状況でも十二分に一緒に働いています。 私たちは1.0リリースの6カ月前にGuiceでこそこそ覗き見をする数人のコアSpring開発者に与えさえしました、そして、彼らは以来ずっと、ソースコードリポジトリアクセス可能でした。
Without further ado, how does Guice compare to Spring?
あとは苦もなく、GuiceはどのようにSpringと比較しますか?と問えます。
Guice is anything but a rehash of Spring. Guice was born purely out of use cases from one of Google's biggest (in every way) applications: AdWords. We sat down and asked ourselves, how do we really want to build this application going forward? Guice enables our answer.
GuiceはSpringの焼き直しどころではありません。Guiceは純粋にGoogleの最も大きい(あらゆる点で)アプリケーションの1つである「AdWords」のユースケースから生まれたました。私たちGuice開発者は、座って、自分達に尋ねました。「このアプリケーションの組み立ては、どのように進めるべきか？」と。Guiceは私たちの答えを可能にしました。
Guice wholly embraces annotations and generics, thereby enabling you to wire together and test objects with measurably less effort. Guice proves you can use annotations instead of error-prone, refactoring-adverse string identifiers.
Guiceは全面的にアノテーションとジェネリックスを採用しました。その結果、はっきりと少ない努力で、テストとオブジェクトとを互いに紐付けすることが可能です。Guiceは、エラーを生みやすく、リファクタリングがしにくいストリング識別子の代わりにアノテーションを使用することができることを証明します。
Some new users fear that the number of annotations will get out of hand. Fear not. You won't have nearly as many different annotations in a Guice application as you have string identifiers in a Spring application.
新しいユーザの中にはアノテーションの数が手に負えなくなると恐れる人もいます。恐れる必要はありません。Guiceアプリケーションには、Springアプリケーションにおけるストリング識別子のほどには沢山のアノテーションはありません。
1. You only need to use annotations when a binding type alone isn't sufficient.
2. You can reuse the same annotation type across multiple bindings (@Transactional for example).
3. Annotations can have attributes with values. You can bind each set of values separately to the same type if you like.
1. バインディングがあるタイプが十分でないときにだけ、アノテーションを使用する必要があるだけで。
2. 複数のバインディング(例えば、@Transactional)の向こう側に同じアノテーションタイプを再利用することができます。
3. アノテーションには値がある属性を持つことができます。 よければ、別々に同じタイプにそれぞれのセットの値を縛ることができます。
Spring supports two polar configuration styles: explicit configuration and auto-wiring. Explicit configuration is verbose but maintainable. Auto-wiring is concise but slow and not well suited to non-trivial applications. If you have 100s of developers and 100s of thousands of lines of code, auto-wiring isn't an option. Guice uses annotations to support a best-of-both-worlds approach which is concise but explicit (and maintainable).
スプリングは、明示的な設定と自動配線の2極構成のスタイルをサポートします:。明示的な設定は、冗長ですがメンテナンス性が高いです。自動配線は、簡潔ですが遅くて重要なアプリケーションにはあまり合いません。100人の開発者と何千ものコードの行が数百もある場合、自動配線は不可欠です。Guiceは簡潔ですが、明示的(メンテナンス性が高い)という良いとこ取りのアプローチをサポートするためにアノテーションを使用します。
Some critics have tried to find an analog to Spring's XML (or new Java-based configuration) in Guice. Most times, there isn't any, but sometimes you can't use annotations, and you need to manually wire up an object (a 3rd party component for example). When this comes up, you write a custom provider. A custom provider adds one level of indirection to your configuration and is roughly 1:1 with Spring's XML in complexity. The remaining majority of the time, you'll write significantly less code.
GuiceでSpringのXML(または、新しいJavaベースの構成)に対して、アナログだという批評家もいました。アノテーションは、ほとんどの場合利用出来ますが、時々使用できないときがあります。そのときは、手動でオブジェクト(例えば、サードパーティーのコンポーネント)を結び付ける必要があります。これが言った場合、カスタムプロバイダーを書くことで対応が可能です。カスタムプロバイダーは、設定に1つのレベルの間接層を加えます。およそ複雑さにおいては、SpringのXMLと1:1です。 残った大部分の時間で、少しだけコードを書きます。
Eric Burke recently ported a Spring application to Guice:
エリック バークは最近GuiceのためのSpringアプリケーションをポストしました。
At the end of the day, I compared my (Guice) modules - written in Java - to my Spring XML files. The modules are significantly smaller and easier to read.
Then I realized about 3/4 of the code in my modules was unnecessary, so I stripped it out. They were reduced to just a few lines of code each.
Oftentimes, it doesn't make sense to port perfectly working code which you won't be changing any time soon to Guice, so Guice works with Spring when possible. You can bind your existing Spring beans. Guice supports AOP Alliance method interceptors which means you can use Spring's popular transaction interceptor.
結局は、私はJavaでかかれた(Guice)モジュールとSpring XMLファイルを比較しました; モジュールは、かなり小さくて読みやすいです。
次に、モジュールのうちおよそ3/4のコードが不要であるとわかったので取り除きました。 それらはそれぞれコードのわずか数行に減少しました。
たいてい、稼動しているコードをいつでもすぐGuiceに完全に移植することに納得がいくというわけではありません。そこで、GuiceはSpringと共に動作することもできます。共同で動作している場合は、既存のSpring Beanをバインドすることができます。 Guiceはその方法のために、AOP Allianceメソッド インターセプターにSpringのポピュラーなトランザクションインターセプターをサポートします。
From our experience, most AOP frameworks are too powerful for most uses and don't carry their own conceptual weight. Guice builds method interception in at the core instead of as an afterthought. This hides the mechanics of AOP from the user and lowers the learning curve. Using one object instead of a separate proxy reduces memory waste and more importantly reduces the chances of invoking a method without interceptors. Under the covers, Guice uses a separate handler for each method minimizing performance overhead. If you intercept just one method in a class, the other methods will not incur overhead.
経験上、ほとんどのAOP枠組みは、ほとんどの用途には強力過ぎるため、AOP自体の概念的な抵抗感を乗り越えられません。Guiceは後からの思いつきの代わりに、コアの中でメソッドインターセプションを組み込みます。 これは、ユーザからAOPの内部実装を隠して、学習曲線を下げます。 別々のプロキシの代わりに一つのオブジェクトを利用すればメモリ浪費を抑えるうえに、より重要なのはインターセプターなしでメソッドを呼び出してしまうという可能性を小さくすることです。内部では、Guiceは性能オーバーヘッドを最小にするハンドラーを各メソッド毎に使用します。クラスのメソッドの1つだけをインターセプトしたとしても、他のメソッドはオーバーヘッドを受けません。
Finally, we knew from the beginning that no matter how much more usable Guice is, it probably shouldn't be too much slower than alternative solutions. Back when we wrote the initial performance tests so we could track Guice's performance as development progressed, we had no idea Guice would turn out to be orders of magnitude faster than some alternatives. Guice's unique builder-style design combined with the new concurrency facilities introduced in Java 5 enables unprecedented performance, some 100X faster than Spring for dependency injection (according to this benchmark).
最終的に、始めから使用可能なGuiceの機能がどれほど多くても、おそらく代替の解決策より目に見えて遅くてはいけないでしょう。開発が進歩したときGuiceの性能を追跡することができるように初期の性能テストを書いたとしても、Guiceが大規模に他の代替手段よりも早くなると判るようなアイデアが思いつきません。Java5で導入する新しいbuilder-styleで結合されたGuiceのユニークなアーキテクトスタイルデザインは、dependency injection (このベンチマークに従って)においては、Springより数百倍速いという空前の性能を可能にします。
