4

MVC4 webapp + EntityFramwork5 の 3 層アーキテクチャを開発しています。レイヤーを分離したいので、たとえば、EFを使用していることをDALだけが知っています。

実際、私はそれを管理するための多くのクラスを持っています:

ダル

  1. エンティティ POCO
  2. エンティティ データ コンテキスト : DbContext
  3. エンティティ リポジトリ

BL

  1. エンティティ ビューモデル
  2. エンティティ サービス (エンティティ リポジトリのインスタンス化)

ウェブ

  1. エンティティ コントローラ (エンティティ サービスのインスタンス化)

これは機能していますが、維持するのは非常に困難です。DAL のエンティティ リポジトリを削除し、DataContext を直接使用することを考えていました (私が間違っていなければ、すべての DbContext がリポジトリと作業単位になるように設計されているため)。私のBLのEntityFramework.dll。大きな問題ではありませんが、それが最良の選択であるかどうかはわかりません。

何かアドバイス？

（十分な情報を提供できれば幸いです。さらに必要な場合は、お問い合わせください）

4

1 に答える 1

5

これとこの 記事を使用できます。

An experienced Architect does not need to go through every single step in the book to get a reasonable design done for a small web

応用。そのようなアーキテクトは、その経験を利用してプロセスをスピードアップできます。以前に同様の Web アプリケーションを作成し、成果物を理解したので、DMS 設計の最初の部分を完成させるために、より高速なアプローチを採用します。この記事の長さを短くするのに役立つことを願っています。

For those who do not have experience, let me briefly mention the general steps that involved in architecturing a software below...

Understand the initial customer requirement - Ask questions and do research to further elaborate the requirement
Define the process flow of the system preferably in visual (diagram) form. I usually draw a process-flow diagram here. In my

最初にシステムの手動バージョンを定義してから、プロセスとそれらの関係を特定しながら、それを自動バージョンに変換しようとしました。ここに示すプロセス フロー図は、取得した要件を顧客と一緒に検証するための媒体としても使用できます。要件に適したソフトウェア開発モデルを特定する 設計開始前に要件を完全に把握して定義したら、「ウォーター フォール」モデルを使用できます。ただし、要件が定義されていない場合は、「スパイラル」のバリアントを使用してそれに対処できます。要件が定義されていない場合、システムは設計中に定義されます。このような場合、後で拡張が予想されるそれぞれのモジュールに十分なスペースを確保する必要があります。使用するアーキテクチャを決定します。私の場合、ドキュメント管理システム (DMS) を設計するために、ASP.NET MVC と多層アーキテクチャ (Three Tier Variant) を組み合わせて使用​​します。システムを分析し、そのモジュールまたはサブシステムを特定します。
一度に 1 つのサブシステムを選択してさらに分析し、システムのその部分に属する詳細なレベルの要件をすべて特定します。データ エンティティを認識し、エンティティ間の関係を定義します (エンティティ関係図または ER 図)。その後、ビジネス エンティティを特定し (一部のビジネス エンティティはシステムのクラスに直接マップします)、ビジネス プロセス フローを定義します。エンティティを整理しました。ここで、データベースを正規化し、使用する OOP の概念と設計パターンなどを決定します。
デザインに一貫性を持たせます。すべてのモジュールとレイヤーで同じ基準に従います。これには、概念の合理化 (例として、同じ目標を達成するために 2 つの異なるモジュールで 2 つの異なる設計パターンを使用した場合、より良いアプローチを選択し、それを両方の場所で使用する)、およびプロジェクトで使用される規則が含まれます。設計の調整は、プロセスの最後の部分です。これを行うには、プロジェクト チームとミーティングを行う必要があります。そのミーティングでは、デザインをチームに提示し、チームに質問させる必要があります。これを機会として、あなたのデザインを正直に評価/調整してください。

于 2013-02-07T07:12:13.763 に答える