7

WSSF を使用して WCF Web サービスを構築しています。アイデアは、サービスを介してメイン データベースを公開し、サービスの上にさまざまなアプリケーションや Web サイトを構築できるようにすることです。現時点では、このサービスからデータをダウンロードして操作し、レポート CSV ファイルとしてユーザーに提供する単純なクライアント アプリを構築しています。

問題は、(データを操作する) ビジネス ロジックをどこに配置するかです。私はそれをサービスの中に入れようと考えました。私はすでに、データベース (顧客、注文など) とほぼ 1 対 1 でマップする単純なオブジェクトを含むビジネス層をそこに持っています。私は、データを操作するためにいくつかの「高レベル」オブジェクトを作成すると考えました。たとえば、顧客、注文、その他のオブジェクトを使用して、レポートなどを作成します。これに最適な場所は、サービスのビジネス レイヤーであると考えました。そうすれば、必要に応じてさまざまなアプリケーションでこのロジックを再利用できます。

残念ながら私の上司は同意しません。彼は「関心の分離」を望んでおり、このロジックの適切な場所は、サービスではなくクライアント アプリ内のビジネス レイヤーであると述べました。これはもっと簡単かもしれませんが、サービス ビジネス レイヤー内で強力なオブジェクト モデルを使用して、このコードを記述したいと思います。サービスによって公開されるオブジェクトは「実際の」オブジェクトではなく、サービス ビジネス レイヤー内に存在する完全なオブジェクト モデルの機能を持たない単なる軽量データ構造です。

皆さんはどう思いますか？

4

3 に答える 3

7

私の投票は明確です：

  • データ整合性チェックをできるだけ多くデータベースに入れます
  • 他のビジネスロジックチェックをサービスのサーバー側のビジネスロジックレイヤーに配置します
  • 「フィールドが必要」などの単純なチェックのみをクライアントレイヤーに配置し、データベースモデルまたはビジネスモデルから最適に自動的に決定します

なぜデータベースなのか？
あらゆる形や形式のSQLには、非常に基本的で非常に強力なチェック機能があります。一意のものであること、テーブル間の関係整合性が指定されていることなどを確認してください。使用してください。データベースでこれらのチェックを行うと、ユーザーが最終的にデータに接続する方法に関係なく（ホラーシナリオ：マネージャーがExcelを使用してテーブルに直接接続し、ビジネスインテリジェンスの作業を行うことができます......）、チェックが実施され、実施されます。データの整合性を強化することは、どのシステムでも最大の要件です。

サーバー上のビジネスロジックはなぜですか？
他の回答者が言及したのと同じ理由：中央集権化。クライアントだけにビジネスロジックとチェックを入れたくはありません。あなたの会社の他の部門またはサードパーティの外部コンサルタントが突然あなたのサービスを使い始めたが、彼らがそれらについて知らないので、すべての検証とビジネスチェックが実施されていない場合はどうなりますか？良くないこと......

クライアントのロジック
はい、もちろんです。特にWebアプリの場合は、クライアントに簡単なチェックを入れたいと思います。「このフィールドは必須」や「このフィールドの最大長」などは、できるだけ早く実行する必要があります。理想的には、これはデータベース/サービス層からクライアントによって自動的に取得されます。ASP.NETサーバーコントロールには、自動的にオンにできるクライアント検証があります。SilverlightRIAサービスは、バックエンドデータモデルのデータ制限を取得して、クライアントレイヤーに転送できます。

于 2009-12-02T05:40:13.640 に答える
0

「正しい」とは、アプリケーションのアーキテクチャによって異なると思います。関心の分離には確かに価値があります。あなたの上司は、現在のモデルは、データベースをビジネス オブジェクトにマップするデータ アクセス レイヤーとしてサーバーを使用することであり、ビジネス ロジックはクライアントに実装する必要があると感じているようです。

ビジネス ロジックがクライアントに実装されているか、サーバーに実装されているかに関係なく、懸念事項を分離することができます。重要なのは処理をどこで行うかではなく、アプリケーションの層の間のインターフェースをどれだけきれいに設計したかです。

クライアントについてもっと知るのに役立つかもしれません。ブラウザ/Javascript クライアントを扱っていますか? もしそうなら、サーバー上で可能な限り多くの処理を維持し、多かれ少なかれ表示したい形式でデータをクライアントに送信します。

それが C# クライアントである場合は、その目的でより多くの機能を使用できます。おそらく、WCF サービスの応答を、サーバー側で使用していたのと同じビジネス オブジェクト クラスに再構成して、サーバー側と同じ能力を得ることができます。(2 つのソリューション間でビジネス オブジェクト クラスを共有するだけです。)

于 2009-12-02T02:08:24.223 に答える
0

これには厳格なルールはありませんが、この場合、あなたよりもあなたの上司の方が間違っていると思います:) これについては、誰もが少しずつ異なる意見を持っているでしょう。ビジネス レイヤー以外の場所に配置しますが、クライアント アプリに配置する理由はほとんどありません。クライアント アプリに配置する場合は、ビジネス ルールではなく UI またはプレゼンテーション ルールであると主張できます。

Web サービスが多くのアプリケーションで使用される場合は、可能な限り Web サービス側のビジネス ロジックが必要です。私は実際には非常に薄い Web サービス レイヤーを持っています。呼び出しを受け入れてから、実際のビジネス レイヤーに実行を渡すだけです。また、データベース データとビジネス データ エンティティ間のマッピングは、ビジネス レイヤーではなく、データベース レイヤーで行います。

于 2009-12-02T02:17:01.173 に答える