2011-01-19 22 views
0

RIAアプリケーションでは、できるだけ多くのビジネスロジックをRIAレイヤー(フラッシュ/シルバーライトなど)の外に配置することになっています。これの背後にある理由は何ですか?プレゼンテーション層に入るロジックは、より速く実行する利点を得ます。プレゼンテーション層にないビジネスロジック

これは、RIAテクノロジがフェイスリフトを必要とする可能性が高く、すべてのビジネスロジックを書き直す必要があるためですか?

+0

性能保証保守性ゲーム – gustyaquino

答えて

5

私はあなたの前提に同意していないと思います。ビジネスロジックをクライアントの外に置くことを想定しています。 です。ビジネスロジックをUIレイヤー外に移動することになっていますが、通常、バックエンドWebサービスを使用する前にクライアント側レイヤーが残っています。典型的なSilverlightアプリケーションは、例えば、ビジネスロジックを持たないビュー、検証とビジネスロジックのかなりのチャンクを持つViewModel、残りを持つモデルを規定するMVVMモデルに基づいています。そしてそのすべてがクライアント側にあります。

一方、実際にはサーバー上にビジネスロジックレイヤーが必要です。クライアント側のアプリケーションを使用して、すべての不良データを除外することはできません。誰かが古いバージョンのクライアントを実行しているか、別のクライアントが完全に動作しているか、システムをハッキングしようとしている可能性があります。

つまり、クライアントとサーバーの両方でビジネスロジックと検証を実行するのが理想的です。クライアントでは応答性が必要なため、サーバーではセキュリティが必要なためです。問題はこれをどうやって得るかであり、完璧な答えはありません。

Silverlightアプリケーションで一般的に採用されているアプローチ(私はFlashに慣れていません)は、クライアントとサーバーの両方で実行される1つの場所で検証を作成できるWCF RIAサービスを使用することです。 WCF RIA Servicesフレームワークを使用していなくても、クライアントとWebサービスの両方の検証/ビジネスロジッククラスのソースコードにリンクすることで、同じ効果を得ることができます。 2回目の検証を書いて手動で同期をとるよりも、おそらく仕事は少なくなるでしょう。

+0

は、外層や内層などに何かを置くことを前提としていないため、シンプルで絶対的に必要な理由でビジネス層が発明されているため、レイヤ間でアルゴリズムを共有しています。 –

0

したがって、1つの理由は保守性です。クライアントがすでにどこにでも配布されている場合は、単純なビジネスルールが変更されたときに、再インストールまたは再ダウンロードを要求する必要はありません。バックエンドに変更を配備するだけで、すべての設定が完了します。

また、ファイアウォールの背後にデータベースを隠すようなこともできます。すべてのビジネスロジックがフロントエンドにある場合、ビジネスロジックをクライアント上で実行できるように、データベースを公開する必要があります。

しかし、私は "ビジネスロジック"が過負荷の言葉であることを恐れています。 "ビジネスロジック"とは何ですか?適切なアーキテクチャは、アプリケーションとニーズに最も合ったアーキテクチャです。

@Ken Smith氏によると、あなたは確かにUIレイヤーでビジネスロジックを避けるべきです。これは、テスト容易性、保守性、デザイン性などです。しかし、これは、特に重要なUIルールを持つRIAアプリケーションの場合、すべてがバックエンドに向かうことを意味するものではありません。 MVVMアプリケーション(Silverlight)またはプレゼンテーションモデルアプリケーション(Flex)では、UI BEHAVIORをViewModelまたはPresentationModelレイヤーに配置します。次に、ビジネスロジックのあらゆるレベルをあなたのモデルに当てはめます。そのビジネスロジックはちょうどいくつかの検証であるかもしれません。もっとそうかもしれない。それはあなたのアーキテクチャに依存します。

1

ビジネスロジックはクロスカッティングの問題です。

ユーザーは日付を入力しますか?そうであれば、インタフェースはピッカーを与える日付であることを知る必要があり、無効なエントリを防止する必要があります。エントリを範囲に制限することさえできます。それがビジネスロジックです。どのようにあなたはそれを保つことができ、まだ有意義なインターフェイスを持っていますか?

ユーザーはいつでも米国の州または県に入居しますか?その場合は、ドロップダウンリストに値を入力する必要があります。これは、UIが外部キーを「認識」していることを意味します。

フィールドは表示されますが、変更はできませんか?なぜ、なぜそうではないのですか?それがビジネスロジックです。特定の条件に基づいて特定のユーザーが実行できることには限界がありますか?それがビジネスロジックです。

これは、UIが約のすべてを意味するわけではありません。ビジネスロジックです。もちろん、多くのデータ移動操作はUIとは関係ありません。

しかし、最終的には、UIからBLをどのように保つべきかということではありません。あなたはそれを行うことができません。問題はUIの中にどのような種類のBLがあるかということです。これは、タイプ、値の範囲、許可された操作などになる傾向があります。

したがって、UIはその情報をすべて下位層から取得するか、その一部をUIレイヤーで再現します。

関連する問題