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; }
}

在我的控制器中，我通常会做这样的事情，从数据库中获取关于一个Employee的数据到我的模型（如果员工列表类似的话）：

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＃类都可以是绑定到视图的模型。如果您的实体框架模型符合视图的业务需求，那么在两者之间添加转换层几乎没有价值。

开发人员通常希望保持数据库模型和应用程序模型分离。这种分离的客观需要取决于正在构建的系统的体系结构。（此问题中没有详细描述。）

相反，同样也有一个论点是由一组无依赖关系的商业模型组成，这些模型在应用程序的每一层都使用。通常通过提出问题来提出这一方面...如果您的用例（用户在视图中执行的操作）与您的系统架构不一致，则不应更改后者以更好地促进前？

简而言之，您肯定可以为应用程序的不同层创建不同模型分类之间的分界线。但是，是否是一个更大的问题。如果在您的情况下这样做会产生额外的工作和额外的复杂性没有任何额外的价值，那么这似乎表明它没有必要。

ASP.net使用实体

1 个答案: