2009-05-09 12 views
1

ASP.NET MVCを使用してWebアプリケーションを作成していますが、ドメイン駆動型設計を使用しようとしています。私は建築の質問があります。ASP.NET MVC/DDDアーキテクチャヘルプ

リストのキーと値を編集できるように保存するWebControlテーブルがあります。私はこれを私のビジネスモデルに取り入れましたが、それは冗長なコードがたくさんあり、それがそこに属しているかわかりません。たとえば、私のリクエストクラスには、NeedTypeというプロパティがあります。これはリストから来ているので、ラジオボタンの値を提供するためにNeedTypeクラスを作成しました。私はここで一つの例を示していますが、そのフォームはおそらくデータベースから来る必要があるダースかそれ以上のリストを持っています。

[編集、質問を明確にする]これを行うにはどうすればよいでしょうか?これらのリストオブジェクトは実際に私のドメインの一部ですか、それともUIのためだけ存在していますか?ドメインの一部ではない場合、それらは私のコアプロジェクトに属しません。そこで彼らはどこに行くのですか?

public class Request : DomainObject 
{ 
    public virtual int RequestId { get; set; } 
    public virtual DateTime SubmissionDate { get; set; } 
    public virtual string NeedType { get; set; } 
    public virtual string NeedDescription { get; set; } 
    // etc. 
} 

public class NeedType : DomainObject 
{ 
    public virtual int NeedTypeId { get; set; } 
    public virtual string NeedTypeCode { get; set; } 
    public virtual string NeedTypeName { get; set; } 
    public virtual int DisplayOrder { get; set; } 
    public virtual bool Active { get; set; } 
} 

public class RequestController : Controller 
{ 
    private readonly IRequestRepository repository; 

    public RequestController() 
    { 
     repository = new RequestRepository(new HybridSessionBuilder()); 
    } 

    public RequestController(IRequestRepository repository) 
    { 
     this.repository = repository; 
    } 

    public ViewResult Index(RequestForm form) 
    { 
     ViewData.Add("NeedTypes", GetNeedTypes()); 
     if (form == null) 
     { 
      form = new RequestForm(); 
      form.BindTo(repository.GetById(125)); 
     } 
    } 

    private NeedType[] GetNeedTypes() 
    { 
     INeedTypeRepository repo = new NeedTypeRepository(new HybridSessionBuilder()); 
     return repo.GetAll(); 
    } 
} 

答えて

3

ビューに必要なデータを含む別個のビューモデルを作成します。 MVCのMのモデルは、ドメインモデルと同じではありません。 MVCビューモデルは、動作のないダムDTOです(プロパティのみ)。ドメインモデルにはできるだけ多くの動作があります。 get; set;を用いたドメインモデル「貧血ドメインモデル」と呼ばれる反パターンとみなされます。ほとんどの人がビューモデルを置く場所は2つあります.Webレイヤーでは、ビューとコントローラーの近く、またはアプリケーションサービスレイヤーにあります。

編集:

あなただけのデータベースとビュー内の1回のリクエストですべてneedtypesの一覧を表示する必要がある、私は確かに、要求やプロパティなどneedtypesのリストと1つのviewmodelを作成します。私はあなたがより大きなアプリケーションを持っていない限り、コントローラ内の複数のリポジトリへの呼び出しが匂いではないと思います。そして、1つのメソッド呼び出しでviewmodel全体を返す別個のアプリケーションサービスレイヤが必要な場合があります。

私は、価値オブジェクトについてのTodd Smithの助言に従うことも良い考えだと思います。 needtypeを実行時にユーザーが追加または編集できる場合、needtypeはエンティティでなければなりません。 needtypeがハードコードされ、プロジェクトの新しいリリースでのみ変更された場合、needtypeは値オブジェクトでなければならず、NeedTypeのリストにNeedType.GetAll()などのデータが格納され、要求テーブルに列を追加してデータベースに格納されます別のneedtypeテーブルの代わりに。

+0

"貧血ドメインモデル"は必ずしも悪いことではありません。たとえば、ドメインオブジェクトの検証ルールは、使用されているプロセスに応じて変更される可能性があります。検証ルールを自分のモデルとは別にすることで、モデルの貧血をより詳細に設定できます。 –

+0

ドメインモデルはエンティティだけではありません。ファクトリ、バリューオブジェクト、リポジトリ、ドメインサービス(認証サービスのようなアプリケーションサービスではない)もドメインの一部です。私はさまざまな場所でさまざまな目的のために検証を使用しますが、それは私のドメインモデルを貧血にしなければならないという意味ではありません。 – Paco

+0

これはオブジェクト指向プログラミングと手続き型プログラミングの違いです。 – Paco

1

リストから来た場合は、私はこれが外来キーであると確信しています。ドメインモデルを設計する際には、あなたのUIはまったく考えないでください。これは、単にNeedTypeが外部キーである場合です。 NeedTypeという文字列を実際のNeedTypeオブジェクトへの参照に置き換えます。データベースでは、これはIDへの参照になります。

NeedTypeの選択肢のリストを作成するときは、すべてのNeedTypeを取得するだけです。もしそれがあまり変わらなければ、それをキャッシュしておくのは良い考えです。

+0

私はあなたが言っていることを理解しています(前のバージョンからデータを移行して、IDではなくテキストを保存することを決定したことに関連する考慮事項があります)。しかし、この表は、フォーム上のリストを編集可能にするためだけに存在するため、ドメインモデルに属しているかどうかはわかりませんでした。 – Leslie

1

あなたのNeedTypeは私にとっての価値オブジェクトのようです。読み取り専用データの場合は、DDDアーキテクチャの値オブジェクトとして扱われ、ドメインの一部です。

DDDを扱うときに、以前のデータベース - > DataTable - > UIのアプローチを使用していないため、多くの人が "冗長すぎる冗長性"問題に遭遇します。

+0

これは私がそれをセットアップした方法です。私は、すべてのリストがまったく同じ5つのプロパティを持つという意味での冗長性についてより心配していました。私はそれらを基本型から継承させることができますが、その基本型は実際にはドメインではなく、ビュー上のリストに関するものです。私はこれを設定する別の方法があるかもしれないと思った。 – Leslie