ASP.Net MVC - 这个实体层是否迈得太远了？

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

海事组织浪费时间。除了最简单的解决方案之外，您将花费太多时间编写映射代码。

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

Answer 3

您正在查看关系数据结构，最好保持第三范式。
从这段代码中，我不明白为什么需要将 FatalHit 与 ZombieDeath 分开。如果将它们合并到一类中，它会失去第三范式吗？其他类是否有 FatalHit 成员？

如果需要两个单独的类来表示这些数据，而第三个组合类仅用于在视图中轻松工作，那么我看不到第三个类的意义。