从不同程序集中的类继承模型的代码优先方法

Question

我有一个解决方案分为两个项目：一个包含我所有模型类的类库（我们称之为 Business）和一个 ASP.Net MVC 项目。

我的 Business 类是通用的，适用于多种类型的项目。因此，它们不包含与其他类的任何数据注释/关联，仅包含成员变量/属性/构造函数。

使用代码优先方法，我应该如何设计我的 ASP.Net 模型以与我的 Business 模型一起使用。

我最初的教导是将我的 Business 类设置为部分类，然后通过添加必要的数据注释/关联来覆盖我的属性。我不能这样做，因为我们正在处理两个独立的项目。

我也在想我可以使用继承。我的 ASP.Net 模型可以从业务类继承，并且我可以在其上添加我的数据注释/关联。不过，这似乎有点混乱和不合逻辑，因为我需要在这个新的子类中定义我的所有构造函数。

有干净利落的聪明方法吗？

编辑：

我的 Business 类通过在属性设置器中抛出异常来进行验证。我的第一个设计是创建我自己的自定义数据注释，它将捕获我的设置器抛出的异常：

public class SetterBasedValidation : ValidationAttribute
    {
        string m_errorMessage = null;
        public SetterBasedValidation(string errorMessage)
        {
            m_errorMessage = errorMessage;
        }

        protected override ValidationResult IsValid(object value, ValidationContext validationContext)
        {
            try
            {
                Type type = validationContext.ObjectType;
                PropertyInfo property = type.GetProperty(validationContext.MemberName);
                property.SetValue(validationContext.ObjectInstance, value);
            }
            catch (Exception)
            {
                return new ValidationResult(m_errorMessage);
            }

            return ValidationResult.Success;
        }
    }

然后我需要一种方法来在我的 ASP.Net 模型类中使用我的自定义数据注释。这会给我想要的结果：

• 保持我的商务课程通用
• 使用我的设置器的验证
• 使用数据注释

Answer 1

将相同的类用于多种用途的想法不是很好。通常，业务类面向（负责）业务逻辑。另一方面，视图模型，因为这通常是您的 ASP.NET MVC 模型文件夹中的内容，负责支持 MVC 应用程序的视图。最后还有数据类（有些人称它们为 DTO），它们是 DAL 的一部分。

所以，从后到前，您应该有数据类、业务类，最后是视图模型，它们构成了绝对最小值适用于中型到大型 Web 应用程序。即使是小型应用程序也可以从这些分离中受益。

现在你可以回忆一下SOLID的第一个字母，也就是单一责任原则，它说：

一个类应该只有一个改变的理由。

（更多关于单一职责原则here。）

您要做的是为您的业务类分配两个角色，即业务和演示、视图模型。所以，比如说，你想覆盖一些新的业务功能，那么你的视图模型肯定会受到影响。另一方面，如果您想添加一些与视图相关的功能（您的情况），您的业务逻辑实现可能会受到威胁。这就像您将它们放入 procrustes bed 中一样。

更糟糕的是，您将这些类称为“通用”类，因此倾向于在​​应用程序的其他部分（可能是 DAL）中使用它们。只是不要。

在您的示例中清楚可见的是，一旦您开始违反基本设计原则，您就会陷入设计问题构建您的应用程序。

所以，坚持众所周知的：

1. 数据类 (DTO) - 位于 DAL 中，
2. 业务对象/类 - 生活在 BL 中，
3. 查看模型 - 位于表示层中。

以这种方式分离您的应用将使您的生活更轻松。