WCF /クライアントアプリ - ビジネスロジックはどこに行くべきですか？

Question

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

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

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

あなたはどう思いますか？助けてくれてありがとう。

乾杯 マーク

Answer 1

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

ビジネスロジックがクライアントまたはサーバーに実装されているかどうかは、依然として分かれています。重要な処理を行う場所ではありませんが、アプリケーションの階層間のインターフェイスをきれいに設計しています。

クライアントについて詳しく知るには役立つかもしれません。あなたはブラウザ/ Javascriptクライアントを扱っていますか？もしそうなら、私はできるだけ多くの処理をサーバー上に保ち、クライアントに表示する形式で多かれ少なかれデータを送信します。

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

Answer 2

これには厳しいルールはありませんが、このケースではあなたの上司があなたよりも間違っていると言います。誰もが少し違うでしょうあなたのビジネスロジックがビジネスレイヤー以外の場所に配置される理由はいくつかありますが、クライアントアプリケーションに入れる理由はほとんどありません。クライアントにいるときはappの場合、ビジネスルールではなくUIルールまたはプレゼンテーションルールです。

ウェブサービスが多数のアプリケーションで使用される場合、可能な限りビジネスロジックをウェブサービス側で使用します。私は実際には非常に薄いwebservice層を持っています、それは、呼び出しを受け入れて、実際のビジネス層に実行を渡すことだけです。データベースレイヤーとビジネスレイヤーのマッピングは、ビジネスレイヤーではなくデータベースレイヤーで行います。

Answer 3

私の投票は明らかである：

• は、サービスのサーバ側のビジネスロジック層に他のビジネス・ロジックチェックを入れ
• データベースへのデータの整合性チェックのほどを入れ
最適に自動的にデータベースモデルから決定され、クライアント層になど「必要なフィールド」、またはあなたのビジネスモデルのような
• 置くだけの簡単なチェック

なぜデータベースですか？
SQLには、非常に基本的で非常に強力なチェック機能があります。物が一意であることを確認してください。テーブル間の関係の完全性が保証されていることを確認してください。USE IT！これらのチェックをデータベースで行うと、ユーザーが最終的にデータにどのように接続しても（恐ろしいシナリオ：管理者がExcelでテーブルに直接接続してビジネスインテリジェンス作業を行うことができます......）チェックが実施され、実施されます。どのシステムでも、データの整合性を確保することが最大の要件です。

なぜサーバー上のビジネスロジックですか？
他の回答者が述べた同じ理由：集中化。ビジネスロジックとチェックはクライアント内でのみ行うことは望ましくありません。あなたの会社のある他の部署または外部のコンサルタントが突然あなたのサービスの利用を開始しても、それらについて知りませんので、すべてのバリデーションとビジネスチェックは行われませんか？ない良いこと......クライアントで

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