問題タブ [spring]

ビジネス サービス クラスで Spring AOP (AspectJ アノテーションと組み合わせて) を使用して、複数のアスペクト (1 つは @Before で、もう 1 つは @Around) を定義することができました。

現在、それらは 1 つずつ (順番に) 呼び出されています。ただし、アスペクトを呼び出す優先度をどのように定義できるか、どこで定義できるかを知りたいです。

Spring AOPに関して私を案内してください。Spring 2.5.3 フレームワークを使用していることに注意してください。

ユーティリティのようなアプリケーションを隅に置き、2 つの異なるデータベースを定期的に更新しています。

これは、Spring Application Context で構築された小さなスタンドアロン アプリです。コンテキストには 2 つの Hibernate セッション ファクトリが構成されており、Spring で構成された Commons DBCP データ ソースを使用しています。

現在、トランザクション管理はありませんが、いくつか追加したいと思います。一方のデータベースの更新は、他方のデータベースの更新が成功するかどうかにかかっています。

アプリは Java EE コンテナー内に存在しません。シェル スクリプトから呼び出される静的ランチャー クラスによってブートストラップされます。ランチャ クラスはアプリケーション コンテキストをインスタンス化し、その Bean の 1 つでメソッドを呼び出します。

データベースの更新にトランザクション性を持たせる「最良の」方法は何ですか?

「最高」の定義はお任せしますが、「設定が簡単」「設定が簡単」「安価」「パッケージ化や再配布が容易」といった機能があればいいと思います。当然FOSSがいいでしょう。

Spring アプリケーションで ApplicationContext のコピーを静的/グローバルに要求する方法はありますか?

メイン クラスがアプリケーション コンテキストを起動して初期化すると仮定すると、コール スタックを介してそれを必要とするすべてのクラスに渡す必要がありますか、またはクラスが以前に作成されたコンテキストを要求する方法はありますか? （シングルトンでなければならないと思いますか？）

依存性注入自体の利点を理解しています。スプリングを例にとってみましょう。また、AOP、さまざまな種類のヘルパーなど、他の Spring 機能の利点も理解しています。次のような XML 構成の利点は何ですか?

次のような単純な古い Java コードと比較して:

これは、デバッグやコンパイル時間のチェックが容易で、Java しか知らない人なら誰でも理解できます。依存性注入フレームワークの主な目的は何でしょうか? （またはその利点を示すコードの一部。）

更新：
の場合

IC フレームワークは、複数ある場合に注入したい myService の実装をどのように推測できますか? 特定のインターフェイスの実装が 1 つしかない場合、IoC コンテナーに自動的にそれを使用するように決定させると、2 番目の実装が表示された後に壊れます。また、インターフェイスの可能な実装が意図的に 1 つしかない場合は、それを注入する必要はありません。

その利点を示す IoC の構成の小さな部分を見ることは本当に興味深いでしょう。私はしばらくSpringを使用してきましたが、そのような例を提供することはできません. また、休止状態、dwr、および私が使用するその他のフレームワークの利点を示す 1 行を示すことができます。

更新 2:
再コンパイルせずに IoC 構成を変更できることを認識しています。それは本当に良い考えですか？誰かが再コンパイルせずに DB 資格情報を変更したいときは理解できます - 彼は開発者ではないかもしれません。実際に、開発者以外の誰かが IC 構成を変更する頻度はどれくらいですか? 開発者にとって、構成を変更する代わりにその特定のクラスを再コンパイルする努力はないと思います。また、開発者以外の場合は、おそらく彼の生活を楽にして、より単純な構成ファイルを提供したいと思うでしょう。

更新 3:

インターフェイスとその具体的な実装の間のマッピングの外部構成

それを外部化することの何がそんなに良いのですか？すべてのコードを外部にするわけではありませんが、ClassName.java.txt ファイルに配置し、その場で手動で読み取り、コンパイルすることはできますが、再コンパイルを回避できます。なぜコンパイルを避けるべきなのですか?!

手続き型コードではなく宣言的にマッピングを提供するため、コーディング時間を節約できます

宣言型アプローチが時間を節約する場合があることを理解しています。たとえば、Bean プロパティと DB 列の間のマッピングを 1 回だけ宣言すると、Hibernate はこのマッピングをロード、保存、HSQL に基づく SQL の構築などに使用します。ここで宣言的アプローチが機能します。Springの場合（私の例では）、宣言はより多くの行を持ち、対応するコードと同じ表現力を持っていました。そのような宣言がコードよりも短い例があれば、それを見てみたいです。

制御原理の反転により、実際の実装を偽の実装に置き換えることができるため (SQL データベースをインメモリのものに置き換えるなど)、単体テストが容易になります。

制御の反転の利点は理解しています (ここで説明する設計パターンを依存性注入と呼びたいと思います。なぜなら、IoC はより一般的だからです。多くの種類の制御があり、そのうちの 1 つ (初期化の制御) だけを反転しています)。なぜ誰かがプログラミング言語以外の何かを必要とするのかと尋ねていました。コードを使用して、実際の実装を偽の実装に置き換えることは間違いなくできます。そして、このコードは構成と同じことを表現します-フィールドを偽の値で初期化するだけです。

DIの利点は理解しています。同じことを行うコードを構成する場合と比較して、外部 XML 構成によって追加される利点がわかりません。私はコンパイルを避けるべきだとは思いません - 私は毎日コンパイルし、今も生きています。DI の構成は、宣言型アプローチの悪い例だと思います。宣言は、一度宣言され、さまざまな方法で何度も使用される場合に役立ちます。たとえば、hibernate cfg のように、Bean プロパティと DB 列の間のマッピングが保存、ロード、検索クエリの作成などに使用されます。Spring DI 構成は、次のように簡単に変換できます。この質問の冒頭のように、コードを構成することはできませんか? そして、それは Bean の初期化にのみ使用されますよね? つまり、宣言型アプローチでは何も追加されないということですよね?

休止状態のマッピングを宣言するとき、休止状態にいくつかの情報を与えるだけで、それに基づいて機能します-何をすべきかは教えません。春の場合、私の宣言は春に何をすべきかを正確に伝えます-では、なぜそれを宣言し、なぜそれをしないのですか?

最終更新:
みんな、多くの回答が依存性注入について教えてくれています。私はそれが良いことを知っています。質問は、コードを初期化するのではなく、DI 構成の目的に関するものです。コードを初期化する方が短くてわかりやすいと思う傾向があります。私の質問に対するこれまでの唯一の答えは、構成が変更されたときに再コンパイルを回避することです。別の質問を投稿する必要があると思います。これは私にとって大きな秘密であるためです。この場合、コンパイルを避ける必要があるのはなぜですか。

コマンドライン引数を解析するSpringコマンドラインアプリケーションを作成している場合、それらをSpringに渡すにはどうすればよいですか？main（）を構造化して、最初にコマンドライン引数を解析してからSpringを初期化するようにしますか？それでも、解析された引数を保持しているオブジェクトをSpringに渡すにはどうすればよいでしょうか。

インデックスには、同一の列を持つ複数のレコードを許可しないUNIQUEデータベース制約があります。

Hibernate（v2.1.8）によって管理され、2つのDAO
getHibernateTemplate().save( theObject )
呼び出しを実行するコードがあり、その結果、上記のテーブルに2つのレコードが入力されます。

このコードがトランザクションなしで実行されると、INSERT、UPDATE、次に別のINSERT、および別のUPDATE SQLステートメントが生成され、正常に機能します。どうやら、シーケンスは最初にDB NULLを含むレコードを挿入し、次に適切なデータでそれを更新することです。

このコードが単一のSpringトランザクションにラップされたSpring（v2.0.5）で実行されると、2つのINSERTが発生し、上記のUNIQUE制約のために即時例外が発生します。

この問題は、ANSI SQLとの互換性がないため、MSSQLでのみ発生します。MySQLとOracleで正常に動作します。残念ながら、私たちのソリューションはクロスプラットフォームであり、すべてのデータベースをサポートする必要があります。

このテクノロジーのスタックがある場合、特定の問題に対する好ましい回避策は何ですか？

アプリケーションのどの部分がコーディングされていませんか? 最も明白な例の 1 つは DB 資格情報であると思います。それらをハードコーディングするのは良くないと考えられています。ほとんどの場合、何かを外部化するかコード化するかを決めるのは簡単です。私にとって、ルールは単純です。次の場合、アプリケーションの一部を外部化する必要があります。

1. 開発者以外でも変更できますし、変更する必要がありますが、UI で定義されたアプリケーション設定 (DB 資格情報、サービス URL など) に含まれることはあまりありません。
2. プログラミング言語を必要とせず、コード化（ローカリゼーション）が不自然に見える

追加するものはありますか？

これは、 spring cfg に関するこの質問に少し関連しています。Spring 構成は、私の実践では開発者以外の誰も変更しないため、あまり明白な例ではないように思えます。そして、外部化の道は、プロジェクト全体がコード化されずに「構成」されるまで、あなたを遠くに連れて行く可能性があります。

したがって、コード化されていない何かを構成することで利益を得たときの経験からいくつかの例をここに投稿してください-春の依存性注入構成など.そして、春を使用する場合-再コンパイルせずに構成が変更される頻度はどれくらいですか?

春に次のようなことをしたい：

これは bean1 の getFoo() メソッドにアクセスし、bean2 の setPropName() メソッドを呼び出すと思いますが、これは機能していないようです。

EclipseでマルチモジュールSpringMVCappfuseアプリケーションをセットアップしようとしていますが、Eclipseにプロジェクトをインポートした後、Eclipseで多くのエラーに直面しているようです。Eclipseでそのようなアプリケーションをセットアップする理想的な方法を示すステップバイステップのガイドラインを誰かが私を助けてくれますか？

完成したばかりのプロジェクトでは、分散トランザクションを機能させる作業を行っていました。

これは、JBoss の Arjuna Transaction Manager と Spring の宣言型トランザクション境界を使用して実装しました。

リクエスト シーケンスは次のようになります。

これが意味することは、保護されたサーブレットにサービスを提供する WAR と、SLSB にサービスを提供する EAR があるということです。

SLSB には、Spring アプリケーション コンテキストをブートストラップするための静的イニシャライザ ブロックがありました。

テクノロジの混在は好きではありませんが、物理的に異なる場所に配置できるプレゼンテーション層とビジネス層の分離は好きです。

Spring を使用するときに、他の人が層を分離するために何を提案しているのか知りたいですか?