WSO2 DSS ドキュメントのほとんどは、既存のデータ ソースを公開するユース ケースに焦点を当てているようです。
新しいサービスをゼロから作成する場合、DSS を使用して新しい CRUD データ アクセス レイヤーを実装しますか、それとも標準の Java ベースのアプローチ (例: spring、hibernate など) を使用してデータ アクセス レイヤーを実装しますか? 新しいサービスに対する両方のアプローチ (DSS と Java) の長所と短所は何ですか?
質問する
325 次
1 に答える
1
IMO、それは、この新しいサービスがいつどこで開発され、ホストされるかによって異なります。1 つのアプリケーションを扱う 1 人のショップであれば、どちらの道をたどっても違いはありません。開発時には、システムの内外を把握し、データ アクセス コードを記述すべき場所、DB とアプリケーション間で転送するデータの種類、およびこの情報がアプリケーションで使用される場所を把握しています。
これが、10 フィートのポールがあっても Web サービスに触れない人がいる理由の 1 つです。追加のオーバーヘッドと複雑さを導入しており、なぜそれが必要なのかを正当化できません。
ある時点で互いに話し合う必要があり、情報を共有したいあらゆる種類のアプリケーションの開発に関与する多数の開発者がいる場所で働いているとしましょう。このような状況では、アプリケーションでデータ アクセス ロジックやその他のビジネス機能を構築するために使用できるライブラリのバージョンを義務付ける内部ポリシーがある可能性があります。このような環境で新しいサービスを導入する場合は、サービスの再利用の可能性を考えたほうが賢明です。新しいサービスを開発し、DB テーブルの上に CRUD インターフェースを平手打ちすると、データ モデルが拡大すると、多くのサービスが作成されます。次に、新しいアプリケーションの場合 これらのサービスを再利用すると、1 つの操作で複数のサービス呼び出しを実行する必要があり、標準以下のパフォーマンスが得られる可能性があります。そのため、パフォーマンスのために JDBC を介してこれらの DB 呼び出しのいくつかを実行する別の複合サービスまたは 2 つを持つことになります。そうすると、すぐにサービスが重複することになります。
この状況を標準の Java ベースのアプローチと比較すると、既存のシステムのいくつかに影響を与える新しいサービスを導入する場合、新しいサービスを利用するには、それらすべてのシステムのコードを記述する必要があります。これらのシステムが、使用しているのと同じバージョンのライブラリ (たとえば、Hibernate) を使用して作成されている場合、作業はいくらか楽になります。これらのシステムがさまざまな方法でさまざまな人々を使用して記述されている場合、人生は再び複雑になります。ここでは、Web サービス呼び出しを行う方がおそらく簡単です。
于 2013-06-10T14:01:26.170 に答える