Question

我正在构建一个比我通常做的更复杂的MVC应用程序，我想尝试一个新的类结构。基本上有很多阅读正在进行中。只有5-10％的操作将针对数据库进行插入/更新。

因此，我正在考虑创建从数据库层返回的基础DTO类。然后，业务对象将从DTO类继承，以便使用所有验证和业务规则扩展基本结构。

示例：

namespace Project.DTO
{
    public class Employee
    {
        public string Name;
        public string Surname;
        ...
    }
}

namespace Project
{
    public class Employee : Project.DTO.Employee
    {
        public bool IsValid()
        {
        ...
        }
    }
}

这是一个好方法吗？我还没有想到的是如何在MVC中使用它们，因为“正确”的方式是实现模型类。我相信我也可以创建从DTO对象继承的模型类......但我不确定。

我还需要一种方法来处理所有验证函数与某种接口，以避免重复GUI上的许多通用代码。

提前致谢！

Answer 1

如果验证必须检查参数必须来自数据库的规则，该怎么办？您的实体将不具备访问该参数的知识和方法。

创建模型/ ViewModel很好但是验证通常需要更复杂的逻辑来保证专用类 - 所以我通常不会在我的实体上实现IsValid。

但是，您可以对实体的简单属性使用System.Component.DataAnnotation验证属性。

Answer 2

我可能会采用完全不同的方法。我的主要想法是：

我想在类之间进行更松散的耦合，所以我不会让我的模型类继承自我的DTO对象
我可能不会在我的模型类中包含验证逻辑

这将导致以下结构：

namespace Project.DTO
{
    public class Employee
    {
        public string Name;
        public string Surname;
        ...
    }
}

namespace Project
{
    public class Employee
    {
        public string Name { get; set; }
        public string Surname { get; set; }
    }
}

当谈到验证逻辑时，我会为验证逻辑创建一个接口，将其注入Emplyee类：

public interface IValidator<T>
{
    bool IsValid(T objectToInspect);
}
public class Employee
{
    private readonly IValidator<Employee> validator;
    public Employee(IValidator<Employee> validator)
    {
        this.validator = validator;
    }

    public string Name { get; set; }
    public string Surname { get; set; }

    public bool IsValid()
    {
        return validator.IsValid(this);
    }
}

这为您提供了一系列功能，包括使用IoC容器和更好的测试支持。

这种类结构方法是正确/可想象的吗？（MVC / C＃）

2 个答案:

这种类结构方法是正确/可想象的吗？ （MVC / C＃）

2 个答案:

这种类结构方法是正确/可想象的吗？（MVC / C＃）