ASP.net与实体合作

Question

我对使用asp.net mvc概念中的实体存在某种误解。

我对asp.net mvc相当陌生，在我学习期间，我被告知，每当我使用数据库时，都必须创建一个模型，该模型将是EF生成的模型的副本。 并发送到视图和所有计算都是使用该模型完成的。

例如，如果我有实体Person，例如：

public int EmployeeId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public Nullable<System.DateTime> DateOfBirth { get; set; }

我必须在Model文件夹中生成类（EmployeeViewModel）：

public class EmployeeViewModel
{
   public int EmployeeId { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public Nullable<System.DateTime> DateOfBirth { get; set; }
}

并且在我的控制器中，我通常会执行以下操作以从数据库获取有关一名雇员的数据到我的模型（如果是雇员列表则类似）：

var Employee = db.Employees.Where(item => item.EmployeeId == someId).Select(item => new EmployeeViewModel
            {
                EmployeeId = item.EmployeeId ,
                FirstName = item.FirstName ,
                LastName = item.LastName ,
                DateOfBirth = item.DateOfBirth 
            }).FirstOrDefault();

这段代码可以工作，但是使用仅作为实体副本的自定义模型的概念似乎很奇怪。.我知道，如果我们的自定义模型与实体不同，则创建自定义模型的概念很有用。

所以还是必须这样做，否则在某些情况下可以直接与实体合作。 如果您能推荐一些文章或其他一些东西来理解这个想法，我将很高兴，我该如何在我的mvc项目中使用数据库，因为从它的原始概念出发这是正确的。

Answer 1

您不必创建所有模型的副本。 实际上，如果它们不过是不会增加任何价值的复本，那么您真的不应该制造它们。

绑定到视图的模型几乎可以是任何C＃类。 如果您的实体框架模型适合视图的业务需求，则在两者之间添加翻译层几乎没有价值。

开发人员经常希望个人喜好将数据库模型和应用程序模型分开。 这种分离的客观需求取决于所构建系统的体系结构。 （此问题中没有描述其详细信息。）

相反，同样存在一个争论，那就是在应用程序的每个层中使用的一组无依赖的业务模型。 这方面通常是通过提出以下问题来提出的：如果您的用例（用户在视图中所做的工作）与您的系统体系结构不符，是否应该更改后者以更好地帮助前者？

简而言之，对于应用程序的不同层，您当然可以在模型的不同分类之间创建一条硬线。 但是，是否应该做的更大。 如果在您的情况下这样做增加了工作量并增加了复杂性而又没有任何附加值 ，那么这似乎表明没有必要。