ASP.NET MVC4 n層アーキテクチャ:最適なアプローチ

MVC4 webapp + EntityFramwork5用の3層アーキテクチャを開発しました。 私は層をsepareteにしておきたいので、DALだけが私がEFを使っていることを知っています。

実際に私はそれを管理するためのクラスがたくさんあります:

DAL

  1. エンティティPOCO
  2. Entity DataContext:DbContext
  3. エンティティリポジトリ

BL

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

WEB

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

これは動作していますが、かなり難しいです。私はDALでエンティティリポジトリを削除し、DataContextを直接使用することを考えていました(すべてのDbContextがリポジトリと作業ユニットになると間違っていない場合)が、私のBLのEntityFramework.dll。大きな問題ではありませんが、それが最良の選択であるかどうかはわかりません。

何かアドバイス?

(私は十分な情報を与えてくれることを願っています。

5
私はそれがあなたのプロジェクトを維持することは難しいと言います。どのレイヤーを維持するのが難しいと思いますか?
追加された 著者 cat_minhv0,
こんにちは@Davide、あなたも同様にプロジェクトのためのいくつかのGOFデザインパターンを適用することができます。たとえば、POCOにフィールドを追加することができれば、「Builder」パターンを使用することができます:)。
追加された 著者 cat_minhv0,
たとえば、私がPOCOにフィールドを追加すると、datacontext(必ずしもそうではない)、dalリポジトリ、BLビューモデル、BLサービスなどを更新する必要があります。構造(または設計エラー)
追加された 著者 Davide,

1 答え

これを使うことができます。 a> これおよびこちらの記事をご覧ください。

 熟練したアーキテクトは、小規模なWebに対して妥当な設計をするために、本の一歩一歩を踏む必要はありません
 
     

アプリケーション。そのような建築家は経験を活かして   プロセス。これまでに同様のWebアプリケーションを作成していたので   私の成果物を理解し、私はより速いアプローチをとるつもりです   私たちのDMS設計の最初の部分を完成させてください。うまくいけば   この記事の長さを短縮するのを助けてください。

 経験のない人には、以下のソフトウェアのアーキテクチャーに関わる一般的な手順について簡単に触れておきましょう。

最初の顧客の要件を理解する - 要件をさらに詳しく説明するために質問をし、研究を行います
好ましくは視覚的(ダイアグラム)の形でシステムのプロセスフローを定義する。私は通常ここにプロセスフローダイアグラムを描きます。私の
 
     

努力、私はシステムのマニュアルバージョンを最初に定義しようとします   それを自動化されたバージョンに変換しようとします   プロセスとその関係を特定する。このプロセスフロー   私たちがここに描いたダイアグラムは、   顧客との間でも要件を満たしています。       要件に合うソフトウェア開発モデルを特定する       要件が完全に取得され、設計開始前に定義されたら、 'Water-Fall'モデルを使用できます。しかし、   要件は定義されていませんが、 'Spiral'のバリアントを使用して   それと。       要件が定義されていない場合、システムは設計中に定義されます。そのような場合は、十分なスペースを確保する必要があります   後で拡張が期待されるそれぞれのモジュールで使用されます。       使用するアーキテクチャを決定する。私の場合は、文書管理システム(DMS)を設計するために、私は、   ASP.NET MVCと多層アーキテクチャ(3層バリアント)       システムを分析し、モジュールまたはサブシステムを識別します。
      一度に1つのサブシステムを選択し、それをさらに分析し、システムのその部分に属するすべての細かいレベルの要件を識別します。       データエンティティを認識し、エンティティ間の関係を定義する(エンティティリレーションシップダイアグラムまたはERダイアグラム)。ができる   その後、事業体を特定する(一部の事業体   あなたのシステムのクラスに直接マップする)、ビジネスを定義する   プロセスフロー。       エンティティを整理しました。ここでデータベースを標準化し、使用するOOPの概念とデザインパターンを決定します   
      デザインを一貫性のあるものにします。すべてのモジュールとレイヤーで同じ基準に従ってください。これには、コンセプトを合理化すること(   たとえば、2つの異なるデザインパターンを2つの   別のモジュールが同じ目標を達成するために、より良い選択   アプローチとその両方の場所での使用)、および   プロジェクト。       設計のチューニングは、プロセスの最後の部分です。これを行うには、プロジェクトチームとの会合が必要です。その中で   あなたのチームにあなたのデザインを提示し、彼らに質問させる必要がある会議   それについての質問。正直に評価する機会としてこれを取る/   あなたのデザインを調整してください。

5
追加された
これはあなたの最初の参考文献からの長い引用であり、番号の付いたリストも含まれていることを明確に述べてください。ありがとう。あなたがリンク専用の答えを出さなかったことはいいことです。
追加された 著者 Gert Arnold,