我很难理解这个词的含义是什么:

Entity,Model,DataModel,ViewModel

任何人都可以帮我理解他们吗？谢谢你们.

关于这个主题有数百个类似的问题.但我仍然感到困惑,我想得到专家的建议.

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

我们在一个单独的项目中有数据层,该项目是一个类库,并包含在其中定义的所有实体.然后使用所有存储库和域模型定义业务层(是要使用的正确术语).然后是表示层.

目前我们还没有定义任何视图模型,我们使用BL中的相同域模型作为视图模型.在这种方法中,一个映射就足够了.

ENTITY <=> DOMAIN模型

但对我来说,它看起来并不像一个好的设计.我更喜欢在表示层中定义视图模型,并使用域模型在表示层和业务层之间进行通信.在BL,将域对象转换为数据实体并与DAL通信.使用这种方法我必须使用两次映射.

查看模型<=>域模型<=> ENTITY

我的域名模型真的有必要吗？我不能使用我的实体与Presentation层进行通信.如果我在表示层中引用实体,是否会产生任何影响？如果有什么样的影响？

我只是花了一些时间阅读这些术语(我没有那么多使用它们,因为我们没有任何MVC应用程序,我通常只说"模型"),但我觉得这些意味着不同的东西取决于上下文:

实体

这很简单,它是数据库中的一行:

2)关于数据库,实体是可以存储数据的单个人,地点或事物.

模型

我经常读到,这基本上是实体的组合以表示一整套数据,假设客户的地址列表模型将实体客户,地址和可能的个体组合在一起.

视图模型

MVVM或MVC模式中的一个术语,它是一个模型,它完全代表您可以在视图上看到的数据.viewmodel位于应用程序层,具有验证属性,即ASP.NET MVC Model vs ViewModel

从我的视线来看,这些术语似乎有点多余:Viewmodel显然已经使用了它,否则视图必须做所有努力才能显示正确的东西.正如我们从EF中所知,实体只是表示,但如果你将这两者结合起来,那么模型的使用在哪里？

必须在ViewModel上完成验证,安全等操作.当你有数百个小表在实体和viewmodel之间放置另一个抽象时,你会使用该模型吗？或者在MVC和MVVM实体和模型方面通常是一样的吗？

像往常一样感谢周末愉快

马蒂亚斯

在领域驱动设计中，领域模型应该完全不知道任何数据持久化细节。

假设 anEmployee属于 a Department。域实体可能如下所示：

public Employee
{
    public string EmployeeId { get; set; }
    public string FirstName { get; set; }
    public string LastName{ get; set; }
    public Department Department { get; set; }
    public int DepartmentId { get; set; }
}

public Department
{
    public string DepartmentId { get; set; }
    public string Name{ get; set; }
}

是Employee.DepartmentId在域模型真正相关的或者是基础设施存储的细节？

Employee.Department在这个层面上，这种关系肯定很重要吗？

就我而言，这些实体将存储在 SQL 数据库中，数据将由实体框架检索，因此Employee.DepartmentId数据库中将存在一列。

编辑：早期的出色反应使我意识到，权衡取舍的问题将结合@Leo的变体会更有用。

我正在Code-First EF中开发数据模型，并且对可能相当基本的内容感到不熟练。

给定团队和玩家类，其中一个团队有N个玩家，则可以设计数据模型

1）以玩家作为成员子对象：

class Team
{
    int Id;
    ICollection<Player> Players;
}

或2）（由于没有实际好处而被拒绝），我们可以将参考ID传递给玩家

class Team
{
    int Id;
    ICollection<int> PlayerIds;
}

或3）使用外键ID实现以实现模型独立性

class Team
{
    int Id;
}

class Player
{
    int Id;
    int TeamId;
}

我可以看到第三种方法的一些明显好处，如下@Leo所示。因此，也许在这一点上，我的问题最好被表述为“在哪种情况下，人们可能更喜欢采用变体1”？

我的项目分层如下：

DAL (Entity)- > BLL (DTO)- > ApplicationComponent (ViewModel)。

将要ApplicationComponent访问的application（）的多个组件BLL。组件包括Windows服务，Web服务，Web API和MVC控制器。

我改造NHibernate Entity的对象DTO对象，而从通过他们DAL来BLL。在将此状态传递给时ApplicationComponent，BLL再次将其转换为ViewModel。

这可以帮助我区分关注点以及如何在每一层中处理数据。我不赞成NHibernate Entity出于以下原因返回对象：-

• 数据暴露给UI我想要隐藏的（或仅在需要时暴露），例如密码，用户类型，权限等。
• 在引用/联接上，NHibernate在访问属性时执行附加查询，这将使延迟加载的使用无效。
• 暴露给（of Entity）用户的不必要数据会造成错误的混淆和漏洞。
• 持久性实现泄漏到BLL/中UI。Entity不适用于UI。它不能UI在所有情况下都可用。
• 我们在属性上使用属性DTO进行用户输入验证，看起来有点奇怪Entity。

我使用这种方法面临以下问题：-

• 最大和明显的问题是具有相似成员和功能的冗余对象。
• 我必须在每一层中编写映射器方法以转换对象。可以通过使用AutoMapper或类似方法将其最小化；但是它不能完全解决问题。

问题：-

1. 是否过度分离，应该避免（至少将其最小化）？
2. 如果这种方法是正确的，那么我看不到任何简单的方法可以完全绕过我上面提到的两个问题。请提出建议。
3. 如果此方法不正确，请提出更正建议。

参考文献：

1. Link1建议将Entity对象转移到视图，在我看来这不是一个好主意。
2. Link2建议Entity …