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

Question

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

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

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

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

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

有没有一种聪明的方法可以干净地做到这一点？

编辑 ：

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

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的第一个字母，即单一责任原则，它指出：

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

（更多关于单一责任原则在这里。）

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

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

在您的示例中清楚可见的是，一旦您开始反对基本设计原则，您就会在构建应用程序时遇到设计麻烦。

所以，坚持众所周知的：

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

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