实体VS领域模型VS视图模型 [英] Entities VS Domain Models VS View Models

问题描述

有数以百计的关于这一主题类似的问题。但我仍然困惑，我希望得到专家建议此

There are hundreds of similar questions on this topic. But I am still confused and I would like to get experts advise on this.

我们正在开发使用ASP.NET MVC 4和EF5和我们的应用程序是DB第一种方法。

We are developing an application using ASP.NET MVC 4 and EF5 and ours is DB first approach.

我们有一个独立的项目，该项目是一个类库，并持有它定义的所有实体的数据层。并与所有的信息库和域模型定义，那么业务层（是要使用正确的术语）。然后是presentation层。

We have Data layer in a separate project which is a class library and holds all the Entities defined in it. And then Business Layer defined with all the repositories and domain models(is that right term to be used). And then comes presentation layer.

在present我们还没有定义的任何视图模型，我们使用相同的域模型从BL的视图模型。在这种方法的一个映射可以是足够的。

At present we have not defined any view models, we are using the same domain models from BL as view models. In this approach one mapping can be enough.

实体LT => DOMAIN模型

ENTITY <=> DOMAIN MODEL

但对我来说，这看起来不像一个好的设计。我preFER有我的presentation层定义的视图模型和使用领域模型$ P ​​$ psentation层和业务层之间的通信。而在BL，转换域对象数据实体和DAL沟通。使用这种方法我都用映射的两倍。

But for me it's not looking like a good design. I prefer to have view models defined in my presentation layer and use domain models to communicate between presentation layer and business layer. And at BL, convert domain objects to data entities and communicate with DAL. Using this approach I have to use mapping twice.

查看型号＆LT; => DOMAIN MODEL＆LT; =>实体

View Model <=> DOMAIN MODEL <=> ENTITY

是我的域模型真的有必要吗？我不能用我的实体presentation层进行通信。是否有任何影响，如果我在我的presentation层引用实体？如果有什么样的影响？

Is my domain model really necessary? Can't I use my entity to communicate with Presentation layer. Are there any impacts if I am referencing Entities in my presentation layer? If there are what kind of impacts?

推荐答案

我觉得你只是具有定义每个层是什么，以及它在解决方案中扮演什么样的角色问题。

I think you're just having issues with defining what each layer is and what role it is playing in your solution.

您的数据层是简单的数据库/ SharePoint列表/ .csv文件/ Excel表...你的想法，它只是在您的数据存储，它可以在任何格式。所以请记住，数据层无非是更多的数据。

Your data tier is simply your database / SharePoint list / .csv file / excel sheet... you get the idea, it's simply where your data is stored, and it can be in any format. So remember that the data tier is nothing more than just data.

// ----------------------------
//    Data tier
//        - MySQL
//        - MS SQL
//        - SharePoint list
//        - Excel
//        - CSV
//        - NoSQL
// ----------------------------

---

数据访问层

这一层抽象了您的数据源，并提供您的应用程序的其他部分可以与数据源进行交互的API。

---

Data Access Layer

This layer abstracts away your data source, and provides an API in which the rest of your application can interact with the data source.

考虑到我们的数据源是一个MS SQL数据库，并且我们正在使用实体框架来访问数据。你会试图抽象掉，是数据库和Entity Framework，并有一个数据存储库每个实体。

Consider that our data source is an MS SQL Database and that we're using Entity Framework to access the data. What you'll be attempting to abstract away, is the database and Entity Framework, and have a Data Repository for each Entity.

我们有一个客户表在MS SQL数据库。在客户表中的每个客户在你的C＃code psented作为这样的实体，并重新$ P $。

We have a Customers table in a MS SQL Database. Each customer in the customers table is an Entity , and is represented as such in your C# code.

通过使用存储库模式，我们可以抽象掉数据访问code的实施，使在未来，如果我们的数据源的变化，我们的应用程序的其他部分不会受到影响。接下来，我们需要一个 CustomersRepository 我们数据访问层，这将包括诸如添加，删除和 FindById 。抽象掉任何数据访问code。下面的例子是，你将如何实现这一目标。

By using the repository pattern, we can abstract away the implementation of the data access code, so that in future, if our data source changes, the rest of our application wont be affected. Next we would need a CustomersRepository in our Data Access Layer, which would include methods such as Add, Remove and FindById. To abstract away any data access code. The example below is how you would achieve this.

public interface IEntity
{
    int Id { get; set; }
}

public class Customer : IEntity
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime RegistrationDate { get; set; }
}

public interface IRepository<TEntity> where TEntity : class, IEntity
{
    TEntity FindById(int id);

    void Add(TEntity entity);

    void Remove(TEntity entity);
}

public class CustomerRepository : IRepository<Customer>
{
    public Customer FindById(int id)
    {
        // find the customer using their id
        return null;
    }

    public void Add(Customer customer)
    {
        // add the specified customer to the db
    }

    public void Remove(Customer customer)
    {
        // remove the specified customer from the db
    }
}

数据访问层属于在该数据层和业务逻辑之间。

The data access layer belongs in between the data layer and business logic.

// ----------------------------
//    Business logic
// ----------------------------

// ----------------------------
//    Data access layer
//        - Repository 
//        - Domain models / Business models / Entities
// ----------------------------

// ----------------------------
//    Data tier
//        - MySQL
//        - MS SQL
//        - SharePoint list
//        - Excel
//        - CSV
//        - NoSQL
// ----------------------------

---

业务层

业务层建立在数据访问层的顶部，并且不与任何数据存取的担忧，但严格的业务逻辑处理。如果业务需求之一是prevent订单正在从英国以外取得，那么业务逻辑层会处理这个问题。

---

Business layer

The business layer is built on top of the data access layer, and does not deal with any data access concerns, but strictly business logic. If one of the business requirements was to prevent orders being made from outside of the UK, then the business logic layer would handle this.

在presentation层只需presents您的数据，但如果你不小心你允许发布后，您设置你的自我为哪些数据您present，哪些数据许多烦恼向下行的，这就是为什么它使用视图模型是非常重要的，因为视图模型是presentation层的关注，presentation层并不需要了解你的域模型什么，只有它需要了解视图模型。

The presentation tier simply presents your data, but if you're not careful about what data you present, and what data you allow to be posted, you'll set your self up for a lot of headaches down the line, which is why it's important to use view models, as view models are a presentation tier concern, the presentation tier doesn't need to know anything about your domain models, it only needs to know about view models.

那么，什么是视图模型......他们这是专为每个视图简单的数据模型，例如登记表将包括 RegistrationViewModel ，揭露这些典型属性。

So what are View Models... They're simply data models which are tailored for each view, for example a registration form would include a RegistrationViewModel, exposing these typical properties.

public class RegistrationViewModel
{
    public string Email { get; set; }
    public string Password { get; set; }
    public string ConfirmPassword { get; set; }
}

在presentation层还处理输入验证，所以例如验证输入电子邮件地址是否具有正确的格式，或者进入比赛的密码是presentation层的关注，没有一家企业的关注，并能通过处理数据注释。

public class RegistrationViewModel
{
    [Required]
    [DataType(DataType.EmailAddress)]
    public string Email { get; set; }

    [Required]
    [DataType(DataType.Password)]
    [Compare("ConfirmPassword")
    public string Password { get; set; }

    [Required]
    [DataType(DataType.Password)]
    public string ConfirmPassword { get; set; }
}

这是使用视图模型重要的原因是因为商业模式属于业务层，它们包括应保持私有数据。举例来说，如果你要揭露域模型的JSON响应，它会为你不是选择性的关于什么是暴露的，哪些不是，但可以使用任何的暴露用户的整个数据，他们的名字他们的地址似乎是工作。

The reason it's important to use View Models is because the Business Models belong to the business layer, and they include data which should remain private. For instance, if you were to expose the Domain Model in a JSON response, it would expose the users entire data, their name their address as you're not being selective about what is being exposed and what isn't, but using whatever that seems to be working.

我还要指出这里有域模型和实体模型之间的差异。有已经是进入了很多更详细的<一个答案href=\"http://stackoverflow.com/questions/18109547/orm-entities-vs-domain-entities-under-entity-framework-6-0?lq=1\">here

I should also point out here that there is a difference between domain models and entity models. There's already an answer that goes into a lot more detail here

我会记住这简短的：

• 异常管理


• 查看模型领域模型映射。
  
  
  • AutoMapper
  
  
  • Exception management
  • Mapping of View Models to Domain Models.
    • AutoMapper

    这篇关于实体VS领域模型VS视图模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！