3

私はアーキテクチャにまったく慣れていないので、次の .NET プロジェクト用にアプリケーションを設計しています。私の提案するアーキテクチャ設計は次のとおりです。

これは、以下を含む従来の 3 層アプリケーションです。 DataLayer (LINQ + 部分クラス) BusinessLogicLayer (エンティティ + 検証ロジック) (オプション) Service Layer (WCF) UI (Web サイトおよび Windows アプリ)

データ レイヤー: データ レイヤーには、DataContext クラス (つまり LINQ) と部分クラスが含まれます。これらの部分クラスには、基本的な計算ロジック (Calc. VAT など) とその他のデータベース レベルの検証ロジックがあります。

ビジネス層: これには、データ層と同様のエントリがありますが、UI レベルの検証ロジックも含まれます。たとえば、ユーザーがデータベースに存在しないユーザー名を入力しようとした場合、ユーザーが存在しないことをユーザーに伝える必要があります。（これは私が苦労している場所です）。オブジェクトは、オブジェクトの作成時ではなく、プロパティが呼び出されるたびに遅延ロードされます。

UI: これは、ビジネス エンティティが呼び出される従来の UI レイヤーになります。

LINQ を使用している場合でも DataLayer からビジネス層を分離している理由は、WCF サービスなどの中間層エンティティを追加したい場合は、Data ではなく Business Layer と通信する必要があるためです。アプリケーションが大きくなると、デカップリングが役立つと思います（と思います）。

誰かが上記の行についてコメントできれば幸いです。私の本当の問題は、ビジネスクラスを書くことです（明らかに）。たとえば、オブジェクトをロードしようとしたときの遅延ロードで、データベースにデータがない場合、ユーザーが存在しないことをUIに表示したい(ユーザー名を検索している場合)。これに関してあなたの推奨事項は何ですか。これへの入力は非常に高く評価されます。

どうもありがとう、Preyash

4

1 に答える 1

2

ここでのアドバイスの1つは、KISS/YAGNIのパラダイムに従うことです。後でアプリケーションが成長したときに必要になると思うからといって、必ずしも複雑なアーキテクチャに飛び込む必要はありません。

たぶん、アプリケーションが何をする必要があるかを正確に調べることから始めて、これを達成できる最も簡単な方法を考えてください。時間を節約し、プロトタイプを非常に迅速に稼働させることができます。これにより、次のバージョンや拡張機能を考慮に入れることができる問題について多くのことを確実に学ぶことができます。

ユーザーインターフェイスに関する質問に関しては、これは、アーキテクチャをシンプルに保つことで他のすべてをシンプルに保つ良い例です。ユーザーが存在しない場合にnullを返すユーザーをロードする簡単なメソッドは、UIで簡単に解釈できます。しかし、複雑なビジネスオブジェクトに入ると、さらに多くの影響について考える必要があります。UIは、単純なデータアクセスCRUDインターフェイスではなく、複雑なビジネスオブジェクトと緊密に結合されるため、アプリケーションは、結合が少なくなるのではなく、結合されるようになったと言えます。

クライアント用のアプリケーションを作成するときの私のアプローチは、通常、サーバー層をできるだけ薄くすることです。データ（つまりデータベース内）のビジネスロジックとUI（つまりクライアント内）のUIロジックを維持しながら、サーバーが行うのは、Webサービスを使用してクライアント/サーバー間で非常に単純なデータオブジェクトを渡すことだけです。

別の方法として、データベース内のロジックのファンでない場合は、ロジックをサービスに配置することもできます。

どちらの場合も、ロジックを新しいビジネスエンティティに配置することにはメリットがあると思います。これを行うと、データを渡してロジックをプライベートに保つのではなく、アプリケーションにロジックを渡して結合を増やすことができるからです。

于 2010-08-19T08:13:35.203 に答える