1

私は現在、設計上 3 層アーキテクチャを持つアプリケーションを開発しています。これは、管理 Web サイト、WCF Web サービス、およびデータベースで構成されています。もちろん、Web サイトはデータベースに直接接続しないため、すべての要求と応答はサービスを通過する必要があります。「問題」は、このアプリケーションに関与するエンティティがいくつかあることです。それぞれのエンティティに対して、基本的な CRUD 操作などをサポートする必要があります。これにより、サービスは現在、単一のエンドポイントで 30 以上のメソッドを持っています。すでに最大メッセージ サイズを増やす必要があったため、これらすべてのメソッドを 1 つのサービスに含めることは多すぎないかどうかを自問し始めました。どう思いますか?どのような代替手段がありますか?

4

3 に答える 3

2

アプリケーションの要件と複雑さに依存するため、良い答えを出すことはできません。通常、CRUDy サービス インターフェイスは避けるべきアンチパターンです。データ層とサービス層の間に 1 対 1 のマッピングがあってはなりません。ある場合、サービス層はそれ自体の重みを引っ張っていません。SOA は、私が理解し始めたばかりの巨大なトピックですが、SOA は多くの操作のロジックをカプセル化することになっていると理解しています。つまり(認証、承認、ロギング、スケーリング、トランザクションなど)

http://msdn.microsoft.com/en-us/library/ms954638.aspx

リポジトリ パターンについて聞いたことがありますか? これは、データベースとの間でデータをやり取りするために必要なロジックを特定のクラス/アセンブリがカプセル化するソフトウェア設計パターンです。本格的なサービスを使用するよりも軽量であり、アプリケーションをデータベースから切り離す良い方法が必要な場合は、これで十分かもしれません。リポジトリ パターンの非常に優れた機能は、リポジトリのすべてのメソッドをインターフェイスにしてから、MockImplementation を作成して、データベースとは独立してビジネス/UI レイヤーでテストを実行できることです。

http://msdn.microsoft.com/en-us/library/ff649690.aspx

于 2011-10-16T20:59:35.540 に答える
1

この質問に対する本当の具体的な答えはありません。どちらにしてもトレードオフです。単一責任の原則を念頭に置いてください。いくつかのオプションは次のとおりです。

  • データ型ごとにエンドポイントを作成し、それぞれに CRUD 操作を入れます。これは、より多くのエンドポイント構成を維持することを意味します。
  • メソッドを複数のファイルに分けますが、部分クラスを使用して 1 つのクラスに残します。
  • データ型ごとに CRUD 操作を行っているだけの場合は、代わりに WCF Data Services / OData を使用してください。
于 2011-10-16T21:02:40.273 に答える
0

WCF サービスを介して反復的な CRUD 機能を実装するのは面倒ですが、サービスがグローバルに公開されていない場合 (認証/承認に多額の費用を支払う必要がないため)、次のいずれかを使用することで多くの時間を節約できます。 2: ADO.NET データ サービスまたは WCF RIA サービス。

1 つのサービスで 30 のメソッドを使用することが悪い設計であるかどうか - これは明確ではありません。これは、30 人のメンバを持つクラスが悪い設計であるかどうかを尋ねるようなものです。間違いなくそうであると言う人もいますが、ほとんどの人は「あなたが何をしているかによる」とコメントします。

それにもかかわらず、CRUD に HTTP を使用すると、いくつかの制限が生じます。メッセージ サイズを増やさない限り、大きなバッチを挿入/更新することはできません。また、明示的な方法で http を介したトランザクションを何らかの形で関与させない限り、トランザクション処理に重大な問題が発生する可能性もあります。

于 2011-10-16T21:10:30.030 に答える