实体模型分离和构造器逻辑答案

【问题标题】：Entity Model Seperation and Constructor Logic实体模型分离和构造器逻辑
【发布时间】：2020-07-07 17:36:22
【问题描述】：

在我们的应用程序中，我们不直接使用 EF Core 实体，而是将它们映射到相应的“模型”类，在大多数情况下看起来完全相同，但实现了 INotifyPropertyChanged 和 INotifyDataErrorInfo。

假设我有一个 TimeSpan 实体和一个 TimeSpanModel。业务逻辑规定时间跨度始终是一年，从 1.1.xx 到 31.12.xx。我喜欢做的是给 TimeSpanModel 一个构造函数：

    public TimeSpanModel(int year)
    {
        From = new DateTime(year, 1, 1);
        To = new DateTime(year, 12, 31);
    }

我想知道，我是否“需要”对实际实体执行相同的操作？实体只能通过将模型实例作为参数的存储库创建。

我觉得我的逻辑会加倍，我必须记住在两个地方更改它。

但它也感觉有点“一半”。它仍然可能创建“错误的”时间跨度实体并将它们持久化到数据库中。如果不加倍逻辑就很难解决。业务层一般都在持久层之上，所以我不应该加倍逻辑，只留下实体吧？

【问题讨论】：

【解决方案1】：

除非您与其他应用共享 EF 模型。

我推荐 2 层。

视图模型匹配但数据呈现方式。

一个模型可以直接从数据库中生成，并且只要您更改数据库结构就可以重新创建。

视图模型应该有前端验证逻辑、数据注释等等。

您的模型不需要知道任何向 UI 通知数据错误的信息。这是视图模型所做的事情之一。

如果您必须与其他应用共享模型，那么您应该考虑将数据注释和验证逻辑放在 dto 中。根据这有多复杂以及您希望如何在 UI 中进行验证，您可能只需要那里的那些。

INotifyPropertyChanged 和 INotifyDataErrorInfo 的实现在所有情况下都在视图模型中。

【讨论】：