5

SOA WCF システムにはデータ アクセス サービスがあります。このサービスは、「システム全体」のデータベース テーブルに対する CRUD (作成、更新、削除) 操作を実行する役割を担い、クエリのこのデータのソースでもあります。DAS の制御下にあるテーブルにアクセスしたいシステム内の他のサービスは、DAS にアクセスして取得または変更する必要があります。Entity Framework を使用し、この DAS 用に独自の POCO 状態追跡システムを構築しました。

データベースには、単一のサービスに属する他のテーブルがあり、データを独自に使用するためだけに保存​​します。つまり、クラッシュして再開した場合にアクセスできる状態情報、またはビジネス情報の記録です。複数のサービスが 1 つのテーブルにアクセスできないという規則があります。そのため、複数のサービスが必要とするデータは DAS に格納されます。

真実は、直接テーブルにアクセスするのではなく、なぜデータ アクセス サービスが良い考えなのか、私は本当に理解したことがないということです。DAS はデータベース更新のために POCO グラフを返すことができないため (一度に 1 つの POCOS のみ)、DAS が実際にはデータを必要とする別のサービスのクライアントである場合にも問題があります。それから...循環依存。

なぜDASを気にするのですか？SOAに関してDASが重要なのはなぜですか? ここで何が欠けていますか？単一の制御ポイント?

すべてのテーブルが DAS の一部であるとは限らず、一部のサービスが独自の「プライベート」テーブルを持っていることも、SOA 設計上の欠陥ですか?

この歓迎についての議論。

4

1 に答える 1

7

これが物事を行うための適切な方法であると考えるのは正しいです。また、物事が遅くなり、時には面倒になる可能性があるということも正しいです。SOA は、サービスに関連付けられたすべてのデータに対して単一の制御ポイントを確保することと引き換えに、必然的にある程度の効率性を犠牲にします。実際、「共通の DAS」サービスを持つという考えでさえ、一部の SOA サークルでは少し臭いです。

すべての CRUD 操作を SOA アプリケーションの 1 つのサービスに一元化することで、データの整合性を確保し、ビジネス ルールが適切に適用されるようにすることができます。例を挙げると、純粋な SQL の観点からアプローチするのが難しいいくつかのビジネス ルールが関連付けられている、保存したいエンティティを考えてみましょう。これらのファイルが存在することを保証するサービス。

SOA とそれらのテーブルへの単一のアクセス ポイントを使用すると、ロジックを作成 / 更新メソッドにコーディングして、サービスから受信するデータが有効であること (つまり、参照されるファイルが存在すること) を合理的に保証できます。誰かがこれらのテーブルに書き込んだり、テーブルからデータを取得したりできる場合、そのような保証は存在しません.自分でサービスを呼び出していても、他のプログラマーが悪意を持って、または単に物忘れを計画して、実装を忘れたのかわかりません.その重要なビジネス ルール。これは、クライアント コードのすべての部分がビジネス ロジックを個別に保証する防御的なプログラミングにつながり、最終的にはアプリケーション全体に散らばるビジネス ロジックのもつれた混乱につながります。

もう 1 つの利点は、スケーラビリティと保守性です。サービスの 1 つが大量のデータにアクセスしているとします。SOA では、すべてが「ブラックボックス化」されているため、クライアント コードは、データが最終的にどのように取得されるかについてあまり知識がありません。RDBMS やパーティション テーブルを変更したり、キャッシングを実装したりして、それを呼び出しているクライアント コードから見えないようにすることができます。アプリ全体にデータベース コードが散らばっていると、この種のアップグレードは非常に苦痛になります。

于 2010-03-02T14:06:06.237 に答える