Question

我有一个域数据模型，它返回一个类，如下所示：

public class ZombieDeath
{
    public virtual int ZombieId {get;set;}
    public virtual FatalHit {get;set;}
}

public class FatalHit
{
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}    
}

将这些数据传回我的网格时，我已经读过，最好始终以平面格式将数据返回给视图。所以我有以下代表网格行的类：

public class ZombieDeathRow
{
    public virtual int ZombieId {get;set;}
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}
}

因此，在呈现此内容时，我只需拨打Model.Weapon，而不是Model.FatalHit.Weapon。它确实使视图的代码更好阅读，但由于需要映射，它显然是一个额外的工作层。

这真的是一种好的工作方式，还是浪费时间？

Answer 1

我认为在域中使用与表示层不同的设计是有好处的。因此，从概念上讲，您实际上在查看两个不同的模型，一个用于域层，另一个用于表示层。每个模型都针对其目的进行了优化。

域层旨在提供独立于您正在使用的用户界面的应用程序域的表示。

表示层中的模型可能会有所不同，具体取决于您使用的用户界面技术或正在使用的客户端。例如，表示层中的模型对于MVC而言可能看起来与WebForms不同（并且有些人并行使用两者）。移动设备的表示层中的模型可能与桌面上运行的浏览器的模型不同。 Web服务可以使用另一个模型来有效地传输数据。如果您在Web应用程序中使用AJAX，您可能更喜欢另一种模型来有效地传输信息，例如使用JSON。

所以，是的，通常我会说只要它们帮助您以易于理解和维护的方式实现您的系统，就可以拥有不同的模型。你提到视图的代码“更好读”。在我看来，这是一个很好的理由！

Answer 2

浪费时间IMO。除了最简单的解决方案外，您将花费太多时间在任何地方编写映射代码。

您在哪里读到最适合展平您的ViewModel？在ViewModel上作为属性公开的复杂业务对象可能不会提升完全封装的代码，但根据我对MVC项目的经验，一个好的域模型意味着除了纯粹主义者之外这不会是一个问题。

Answer 3

您正在查看关系数据结构，最好保持第3范式。从此代码中我不明白为什么您需要将FatalHit与ZombieDeath分开。如果你把它们组合在一个类中，它会失去第三种常规形式吗？其他课程有FatalHit个成员吗？

如果需要2个单独的类来表示这些数据，而第三个组合类仅用于在视图中轻松使用，我在第三类中没有看到这一点。

ASP.Net MVC - 这个实体层是否太过分了？

3 个答案: