1

いくつかのサービスがあり、それぞれが理想的には互いに独立して動作する必要があります。サービスの主な用途は、Web アプリケーションをサポートすることです。私たちは、これらのサービスでibatisを使用する最良の方法を探しています.

最初のアプローチは、SqlSessionFactory を含む 1 つのプロジェクトを作成し、すべてのサービス実装でそのプロジェクトをデータ アクセスに使用することでした。これは、プロジェクトがデータ オブジェクトのすべてのサービスに依存し (サークルの依存関係を排除するためにサービスと impl を分離する必要があった)、すべての SQL マップが含まれていることを意味します。利点は、いつでも SqlSessionFactory の 1 つのインスタンスと、管理する 1 つの構成です。ただし、junits やその他のユーティリティのように 1 つのサービスが使用されている場合、すべての sql マップは関係なく読み込まれ、すべてのサービスは依存関係にあります。

別のアプローチは、各サービスに独自の ibatis 構成と SqlSessionFactory のインスタンスを持たせることです。これは、データ アクセス プロジェクトへの依存のメッカの必要性を回避しますが、webapp での SqlFactory の複数のインスタンスを意味します。

私は 2 番目のアプローチが好きですが、どちらにも良い面と悪い面があります。

あなたならどうしますか？あなたは私の議論に何を追加または削除しますか?

助けてください！！！

4

3 に答える 3

2

あなたの最初の議論の強さは、SOA の一般的な弱点を示していると思いますが、SOA を行っている場合、すべてのサービスを相互に依存させるという目的全体が無効になると思います。

SOA を実行している場合は、コンポーネントの分離と分離のために、より非効率的なリソース使用のトレードオフを受け入れています。

于 2010-11-05T01:47:19.710 に答える
1

正直なところ、パフォーマンスのボトルネックが見つかるか、アプリケーションが大きくなりすぎるまでは、単純にしておいてください。つまり、サービスが独自のスケジュールで個別に更新されることを期待しない限りです。

私が働いている場所には、すべてのアプリケーションで共有される共通のコードがあります。すべて同じソースから提供されますが、各アプリケーションに個別に組み込まれています。これはおそらく最善の解決策ではありませんが、少なくとも、別のアプリがデプロイされることを心配することなく、共通のコードを簡単に変更できます。また、以前にデプロイされたアプリに影響を与えることなく、より多くのアプリケーションが導入されたときに共通のコードを変更できます。

于 2010-11-05T02:04:03.523 に答える
0

両方のソリューションを適用できる場合は、すべてのサービスを同じ JVM で実行している可能性があります。私の意見では、コンポーネントを別々の JVM で実行することを検討する必要があります。真のサービス コンポーネント アーキテクチャとは、複数のコンポーネント (EJB など) がクラスター化された環境で実行され、疎結合された有人 (JMS や Web サービス、RMI などを介して) で互いに通信するアーキテクチャです。各コンポーネントは独立しており、場合によってはリモート サーバーで実行されます。

この場合、もちろん 2 番目の方法を使用します。ただし、アプリケーションでこのデカップリングが必要ない場合は、最初のアプローチを使用する必要があります。これは、メモリ効率が高いためです。

結局のところ、アプリケーションが本当に必要とするものは何かという問題です。

于 2010-11-12T09:21:56.963 に答える