构建视图模型的最佳方法是什么？ [英] What is the best way to build view model?

问题描述

我正在使用asp.net mvc与实体框架，并开始学习DDD。我正在开展包含调查的项目。这是我的域名模型：

  public class Survey 
 {
 public int？ SurveyID {get;组; } 
 public string Name {get;组; } 
 public decimal MinAcceptanceScore {get;组; } 
 public int UserFailsCount {get;组; } 
 
 public IEnumerable< SurveyQuestion>问题{get;组; } 
 public IEnumerable< Prize>奖品{get;组; } 
 public IEnumerable< SurveyAttempt> UserAttempts {get;组; } 
} 
  

我为不同的视图需要不同的调查部分，所以我创建了不同的ViewModels：

  public class ShortSurveyViewModel 
 {
 public int？ SurveyID {get;组; } 
 public string Name {get;组; } 
 public int UserFailsCount {get;组; } 
 public IEnumerable< SurveyAttempt> UserAttempts {get;组; 
} 
 
 public class ShortSurveyWithPrizesViewModel 
 {
 public int？ SurveyID {get;组; } 
 public string Name {get;组; } 
 public int UserFailsCount {get;组; } 
 public IEnumerable< SurveyAttempt> UserAttempts {get;组; } 
 public IEnumerable< Prize>奖品{get;组; } 
} 
 
 public class SurveyEditViewModel 
 {
 public int？ SurveyID {get;组; } 
 public string Name {get;组; } 
 public decimal MinAcceptanceScore {get;组; } 
 public int UserFailsCount {get;组; } 
 
 public IEnumerable< SurveyQuestion>问题{get;组; } 
 public IEnumerable< Prize>奖品{get;组; } 
} 
  

如果我想要我的调查，建立我的架构的最好方法是什么存储库获取适当视图模型所需的信息？

我看到的不同的解决方案：

1. 存储库可以将IQueryable返回给SurveyService，服务可能返回自适应视图模型，但我犹豫，这样做是正确的，因为我认为视图模型应该在UI中创建，而不是服务层。




2. 在我的域图层中创建三个适当的类。但是现在域将依赖于表示，并且每个新视图都应该创建新的域类。




3. 检索完整的域对象，并仅映射特定需要的属性视图。这不是很好，因为在我的示例中，问题只需要一个表示，它可能是很重的收集。

解决方案

域驱动设计：

• 您应该有一个存储库返回聚合根 - 在您的情况下调查和不存在的所有关系，如果没有父级调查


• 此存储库将总是加载整个调查类，根据你的要求只是一些关系（真正教条的DDD总是加载整体聚合，但这不是一个很好的无状态网络的方法）。


• 您的应用层（控制器）将询问调查的库，并选择关系并填充视图模型。

洋葱结构：

• 您将创建一些资料库，显示 IQueryable< Survey> ; - 更糟糕的是，您将使用通用存储库与CRUD inter面对


• 您将创建一些服务调用库，并将Linq对实体投影构建到您的DTO中并将其返回到应用程序层（控制器）


• 怎么办？您可以直接使用这些DTO或使用另一组对象作为您的视图模型与一些UI相关属性等。显然有些错误...

简单的架构：

• 您将使用注入的 IDbSet< Survey> 直接在控制器中作为存储库


• 您将直接在控制器中将Linq对实体投影填充视图模型

没有最好的方法。它总是关于你的目标和你的期望。对于小型应用程序，您可以使用简单的架构，而不会出现问题

域驱动设计更加复杂。 DDD的主要概念是域实体，价值对象及其组成。域实体封装了对这些数据执行的数据和逻辑。 DDD不适用于部分数据或DTO - 当您的域实体没有任何错误的逻辑（称为贫血模型）时。 DDD中的服务不是应用层和存储库之间的中介。它用于处理与单域实体无关的业务逻辑（因此不能封装在域实体中）。存储库是从存储实现聚合并将其持久存储的基础设施代码。应用程序逻辑（控制器）可以与域实体，服务和基础设施代码交互。

我不喜欢洋葱架构。

I'm using asp.net mvc with entity framework and starting to learn DDD. I'm working on project that contains surveys. Here's my domain model:

public class Survey
{
    public int? SurveyID { get; set; }
    public string Name { get; set; }
    public decimal MinAcceptanceScore { get; set; }
    public int UserFailsCount { get; set; }

    public IEnumerable<SurveyQuestion> Questions { get; set; }
    public IEnumerable<Prize> Prizes { get; set; }
    public IEnumerable<SurveyAttempt> UserAttempts { get; set; }
}

I need different parts of surveys for different views so I've created different ViewModels:

    public class ShortSurveyViewModel
    {
        public int? SurveyID { get; set; }
        public string Name { get; set; }
        public int UserFailsCount { get; set; }
        public IEnumerable<SurveyAttempt> UserAttempts { get; set; }
    }

    public class ShortSurveyWithPrizesViewModel
    {
        public int? SurveyID { get; set; }
        public string Name { get; set; }
        public int UserFailsCount { get; set; }
        public IEnumerable<SurveyAttempt> UserAttempts { get; set; }
        public IEnumerable<Prize> Prizes { get; set; }
    }

    public class SurveyEditViewModel
    {
        public int? SurveyID { get; set; }
        public string Name { get; set; }
        public decimal MinAcceptanceScore { get; set; }
        public int UserFailsCount { get; set; }

        public IEnumerable<SurveyQuestion> Questions { get; set; }
        public IEnumerable<Prize> Prizes { get; set; }
    }

What would be the best way to build my architecture if I want my survey repository to get information needed for appropriete view model?

Different solusions that I see:

1. Repository could return IQueryable to SurveyService and service could return the appropriete view model, but I hesitate that doing this is right because I think view models should be created in UI, not Service layer.

2. Create three appropriate classes in my domain layer. But now domain will be dependent from representation and with each new view new domain class should be created.

3. Retrieve full domain object and map just properties that needed for particular view. This is not good because in my example Questions only needed in one representation and it could be heavy collection.

解决方案

Domain driven design:

• You should have a repository returning aggregate root - in your case Survey and all relations which cannot exist without parent Survey
• This repository will load always whole Survey class and depending on your requirements just some relations (the really dogmatic DDD would always load whole aggregate but that is not a good approach for stateless web).
• Your application layer (controller) will ask repository for Survey and selected relations and fills view models.

Onion architecture:

• You will create some repository exposing IQueryable<Survey> - even worse you will use generic repository with CRUD interface
• You will create some service calling repository and building Linq-to-entities projection into your DTOs and returning them to application layer (controller)
• Now what? You can either use those DTOs directly or use another set of objects used as your view models with some UI related attributes etc. There is obviously something wrong ...

Simple architecture:

• You will use injected IDbSet<Survey> directly in your controller as a repository
• You will make Linq-to-entities projections directly in your controller to fill view models

There is no best way. It is always about your goal and about your expectations. For small applications you can live with simple architecture without any issue.

Domain driven design is more complex. The main concept in DDD are domain entities, value objects and their composition. Domain entity encapsulates data and logic executed on those data. DDD does not work with partial data or DTOs - when your domain entities don't have any logic you are doing it wrong (it is called anemic model). The service in DDD is not mediator between application layer and repository. It is used to handle business logic which is not related to single domain entity (so cannot be encapsulate in domain entity). Repository is infrastructure code needed to materialize your aggregates from storage and to persist them in storage. Application logic (controller) can interact with domain entities, services and infrastructure code.

I don't like onion architecture.

这篇关于构建视图模型的最佳方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！