6

システムを一から設計・実装しなければならない状況です。アーキテクチャについていくつか質問があるので、コメントや考えをお願いします。

プロジェクトに関するクイック情報: データ中心の Web アプリケーションです。

アプリケーションは、MS SQL SERVER 2008 データベースを使用する Microsoft .NET Framework 4.0 上に構築されます。

要件：

  1. 豊富な UI と堅牢性
  2. マルチデバイスのサポート (すべてのブラウザーとすべてのデバイス)
  3. 疎結合

以下は、私が構築したアーキテクチャ図です。

ここに画像の説明を入力

アーキテクチャのブリーフィング

  1. プレゼンテーション層 : HTML5/ASP.NET MVC + JQuery (最初のバージョンではマルチデバイス対応の Web アプリケーション)
  2. 分散サービス : WCF (XML/JSON/JSONP)
  3. Domain Layer(Business Layer) : すべてのビジネスロジック
  4. データの永続性 (DAL レイヤー) : データベース ファースト アプローチの Entity Framework 4.0。POCO エンティティは、T4 テンプレートを使用して生成および分離されます
  5. インフラストラクチャ層: POCO エンティティ、例外処理、ロギングなどの共通ライブラリが含まれています。

私の懸念：

  1. アプリケーションは疎結合で構築されるため、将来的にビジネス要件が増大した場合、アーキテクチャに影響を与えることなく新しいモジュールを簡単にプラグインできます。そこで、IoC と DI と共にリポジトリ パターンを使用することを考えました (Unity/Ninject/Sprint.NET またはその他のいずれでもかまいません)。
  2. XML と JSON の両方をサポートする WCF
  3. IoC & DI を配置する分散サービス層
  4. Enterprise Library 5.0 を使用した例外処理とログ記録

貴重なコメントや提案を探しています。私が何か間違ったことをしている場合は、私を正しい方向に向けてください。

4

4 に答える 4

6

次のコメントをお勧めします。最初から、アプローチは密結合を作成します。これは、要件＃3「疎結合」に直接反します

ダイアグラムでは、2 つのモジュールを定義しました。メイン モジュール、およびモジュール 2。これら 2 つのモジュールは互いにまったく異なるものだと思います。これが意味することは、それらが対処するビジネス上の懸念が異なるため、それらを完全に個別に開発してからプラグインできるということです。

ただし、現在のアーキテクチャ アプローチ:

  • メインモジュールとモジュール 2 のデータを同じデータベースに結合
  • メイン モジュールとモジュール 2 ビジネス オブジェクトを同じビジネス レイヤーに結合します。
  • メイン モジュール サービスとモジュール 2 サービスを同じサービス レイヤーに結合します。
  • メイン モジュールとモジュール 2 の展開と管理を結合します。

考慮すべき点: メイン モジュールとモジュール 2 を個別の垂直サービス スタックとして構築します。

つまり、メイン モジュールとモジュール 2 がメイン サービスとサービス 2になるということです。

各サービスには、独自のデータベース、独自のビジネス層、独自のサービス層、および独自の UI コンポーネントがあります。

ただし、これにより懸念が生じます。メイン サービスとサービス 2 の両方がどのように連携して製品を作成できるのでしょうか?

これに対処するには:

  1. UI エンドでは、クライアント側のコードを使用してメイン サービスとサービス 2 からの応答を 1 つのビューに読み込むことで、フロント エンドをつなぎ合わせます。

  2. バックエンドでは、パブリッシュ サブスクライブ メッセージングを使用して、メイン サービスがサービス 2 で発生するイベントをサブスクライブできるようにします。

これにより、メッセージの非同期交換によって一貫性を維持する、疎結合された垂直サービス スタックの上にアプリケーションがゼロから構築されます。

その後、アプリケーションに新しいモジュールを追加する必要がある場合は、目的の機能をサポートする新しいサービス スタックを作成し、他のスタックにほとんどまたはまったく変更を加えることなく接続できます (理想的には、既存のスタックを変更する唯一の理由です)。新しいモジュールからのイベントをサブスクライブしたいということです)。

これは、あなたが提案しているものとは非常に異なるアプローチですが、私の意見では、疎結合の要件をより適切に満たすことができます。

于 2012-01-18T09:38:19.933 に答える
1

アーキテクチャ図で ASP.NET のドメイン層を使用していないのはなぜですか?

アプリケーションをオーバーアーキテクチャ化しているように思えます。また、6 つ (またはそれくらい) の異なるフロントエンド テクノロジをサポートすることは素晴らしいように見えますが、それらすべてを維持するのは大変なことです。フロントエンドには 1 つのテクノロジに固執します。ほとんどの場合、クライアント側の MVC を使用した HTML5 などです。

于 2012-01-18T09:29:45.513 に答える
1

WPF、WinForm などの UI が WCF レイヤーを呼び出す必要があることは理にかなっています。複数の UI を持つことがビジネス要件であると想定しています。それ以外の場合、UI を 1 つしか持てない場合は、レスポンシブ Web UI が最も柔軟な選択肢です。

ただし、MVC UI で WCF レイヤーを使用する必要はないと思います。ドメイン層を直接呼び出すことができます。それはより速く、無意味なレイヤーを削除します。

明らかに、これは、WCF レイヤーにロジックを配置しない限り機能します。また、WCF レイヤーにはロジックを含めるべきではありません。

また、IoC と DI を分散サービス層に配置したいと述べています。これは、MVC UI に関してはあまり意味がありません。コントローラーを単体テストできるように、MVC プロジェクトで DI を使用する必要があります。

于 2012-01-18T09:24:40.907 に答える
0

あなたの図を見ると、はっきりしない点がいくつかあります。

  • ドメイン モデルはどこにありますか? ドメインコアまたは永続層の「モデル」?
  • ドメイン層はデータ アクセス層とどのように相互作用しますか? 相互作用は、サービス/アプリケーション層とドメイン層の間ほど明確ではありません。
  • ドメイン層のリポジトリとデータ アクセス層のリポジトリの違いは何ですか? 私は通常、ドメイン モデル オブジェクトに作用するドメイン層の「モデル リポジトリ」と、DTO に作用するデータ アクセス層の「データ ゲートウェイ」を区別します。
  • ドメインコアとは？これはアプリケーション層トランザクションの実装ですか?
  • 永続化フレームワークをさらに抽象化する必要はありますか? (EF)
于 2012-01-18T09:41:16.487 に答える