将业务层与数据层分离时对实体进行限制的位置

Question

我正在尝试为我的大型 ASP.NET MVC 应用程序创建业务层和数据层。因为这是我第一次尝试这种规模的项目，所以我正在阅读一些书籍，并努力小心地将事物正确地分开。通常，我的应用程序混合了业务逻辑和数据访问层，并且多个业务实体在单个类中交织在一起（当我试图弄清楚在哪里添加内容时，这让我很困惑）。

我读过的大部分内容都是将业务层和数据层分开。这看起来一切都很好，但我很难想象在某些情况下如何做到这一点。例如，假设我正在创建一个允许管理员向系统添加新产品的系统：

public class Product
{ 
   public int Id { get; private set; }
   public string Name { get; set; }
   public decimal Price { get; set; }
}

然后我通过创建存储库来分离数据访问

public class ProductRepository
{
   public bool Add(Product product);
}

假设我希望要求产品名称至少包含 4 个字符。我不知道如何干净地做到这一点。

我的一个想法是扩展 Name 的 set 属性，并且仅在长度为 4 个字符时才设置它。但是，创建产品的方法无法知道名称未设置，除非 Product.Name != 他们传入的任何内容。

我的另一个想法是将其放入 Add() 方法中存储库，但随后我的业务逻辑和数据逻辑就在那里，这也意味着如果 Add 调用失败，我不知道它是业务逻辑失败还是因为 DAL 失败（这也意味着我可以'不要使用模拟框架来测试它）。

我唯一能想到的就是将我的 DAL 内容放在第三层中，该第三层从存储库中的 Add() 方法调用，但我在我的书或网站上的任何域建模示例中都没有看到这一点。网络（至少我见过）。当我不确定是否需要时，它还会增加域模型的复杂性。

另一个示例是希望确保名称仅由一个产品使用。它会放在 Product 类、ProductRepository Add() 方法中还是哪里？

附带说明一下，我计划使用 NHibernate 作为我的 ORM，但是，要实现我想要的目标（理论上），我使用什么 ORM 并不重要，因为 TDD 应该能够隔离所有这些。

提前致谢！

Answer 1

我通常通过使用分层架构来解决这个问题。如何做到这一点？您基本上拥有以下（理想情况下）VS 项目：

• 表示层（UI 内容所在的位置）
• 业务层（实际业务逻辑所在的位置）
• 数据访问层（与底层 DBMS 通信的位置）

为了解耦所有这些，我使用了- 称为界面层 最后我有

• 表示层（其中 UI
  东西驻留）
• IBusiness层（包含接口
  业务层）
• 业务层（其中
  实际的业务逻辑驻留在）
• IDataAccess 层（包含
  DAO 层的接口）
• 数据访问层（在其中进行通信）
  与您的底层 DBMS）

这非常方便，并且创建了一个很好的解耦架构。基本上，您的表示层仅访问接口，而不访问实现本身。为了创建相应的实例，您应该使用 Factory 或最好使用一些依赖项注入库（Unity 适用于 . Net 应用程序或 Spring.Net）。

这对您应用的业务逻辑/可测试性有何影响？
详细编写所有内容可能太长，但如果您担心拥有良好的可测试设计，则绝对应该考虑依赖项注入库。

使用NHibernate，...无论什么ORM
通过接口将 DAO 层与其他层完全分离，您可以使用背后的任何技术来访问底层数据库。您可以根据需要直接发出 SQL 查询或使用 NHibernate。好处是它完全独立于应用程序的其余部分。您可以从今天开始手动编写 SQL，明天将您的 DAO dll 与使用 NHibernate 的 dll 交换，而无需对 BL 或表示层进行任何更改。
而且测试你的 BL 逻辑很简单。您可能有这样的类：

public class ProductsBl : IProductsBL
{

   //this gets injected by some framework
   public IProductsDao ProductsDao { get; set; }

   public void SaveProduct(Product product)
   {
      //do validation against the product object and react appropriately
      ...

      //persist it down if valid
      ProductsDao.PersistProduct(product);
   }

   ...
}

现在，您可以通过在测试用例中模拟 ProductDao 来轻松测试 SaveProduct(...) 方法中的验证逻辑。

Answer 2

将产品名称限制等内容放入域对象 Product 中，除非您希望在某些情况下允许少于 4 个字符的产品（在这种情况下，您可以在控制器和/或客户端的级别）。请记住，如果您共享该库，您的域对象可能会被其他控制器、操作、内部方法甚至其他应用程序重用。无论应用程序或用例如何，您的验证都应该适合您正在建模的抽象。

由于您使用的是 ASP .NET MVC，因此您应该利用框架中包含的丰富且高度可扩展的验证 API（使用关键字 IDataErrorInfo MVC Validation Application 进行搜索阻止 DataAnnotations 了解更多）。有很多方法可以让调用方法知道您的域对象拒绝了某个参数——例如，抛出ArgumentOutOfRangeException。

对于确保产品名称唯一的示例，您绝对不会将其放入 Product 类中，因为这需要了解所有其他 Product s。这在逻辑上属于持久层，并且可选地属于存储库。根据您的用例，可能需要一个单独的服务方法来验证该名称尚不存在，但您不应该假设当您稍后尝试保留该名称时它仍然是唯一的（它已再次检查，因为如果您验证唯一性，然后在持久化之前将其保留一段时间，其他人仍然可以持久化具有相同名称的记录）。

Answer 3

我就是这样做的：

我将验证代码保留在实体类中，该实体类继承了一些通用的 Item Interface。

Interface Item {
    bool Validate();
}

然后，在存储库的 CRUD 函数中，我调用适当的验证函数。

这样，所有逻辑路径都在验证我的值，但我只需要在一个地方查看即可了解验证的真正含义。

另外，有时您会使用存储库范围之外的实体，例如在视图中。因此，如果验证是分开的，则每个操作路径都可以测试验证而无需询问存储库。

Answer 4

对于限制，我利用 DAL 上的部分类并实现数据注释验证器。通常，这涉及创建自定义验证器，但效果很好，因为它完全灵活。我已经能够创建非常复杂的相关验证，甚至作为有效性检查的一部分访问数据库。

http://www.asp.net /(S(ywiyuluxr3qb2dfva1z5lgeg))/learn/mvc/tutorial-39-cs.aspx

Answer 5

为了与 SRP（单一职责原则）保持一致，如果验证是与产品的域逻辑分开。由于它是数据完整性所必需的，因此它可能应该更接近存储库 - 您只想确保验证始终运行而无需考虑。

在这种情况下，您可能有一个通用接口（例如 IValidationProvider），它通过 IoC 容器或您的偏好连接到具体实现。

public abstract Repository<T> {

  IValidationProvider<T> _validationProvider;    

  public ValidationResult Validate( T entity ) {

     return _validationProvider.Validate( entity );
  }

}  

这样您就可以单独测试您的验证。

您的存储库可能如下所示：

public ProductRepository : Repository<Product> {
   // ...
   public RepositoryActionResult Add( Product p ) {

      var result = RepositoryResult.Success;
      if( Validate( p ) == ValidationResult.Success ) {
         // Do add..
         return RepositoryActionResult.Success;
      }
      return RepositoryActionResult.Failure;
   }
}

如果您打算通过外部 API 公开此功能，则可以更进一步，并添加一个服务层来协调域对象和数据访问。在这种情况下，您将验证移至服务层并将数据访问委托给存储库。您可能有，IProductService.Add( p )。但由于层数都很薄，维护起来可能会很痛苦。

我的 0.02 美元。

Answer 6

通过松散耦合实现此目的的另一种方法是为您的实体类型创建验证器类，并将它们注册到您的 IoC 中，如下所示：

public interface ValidatorFor<EntityType>
{
    IEnumerable<IDataErrorInfo> errors { get; }
    bool IsValid(EntityType entity);
}

public class ProductValidator : ValidatorFor<Product>
{
    List<IDataErrorInfo> _errors;
    public IEnumerable<IDataErrorInfo> errors 
    { 
        get
        {
            foreach(IDataErrorInfo error in _errors)
                yield return error;
        }
    }
    void AddError(IDataErrorInfo error)
    {
        _errors.Add(error);
    }

    public ProductValidator()
    {
        _errors = new List<IDataErrorInfo>();
    }

    public bool IsValid(Product entity)
    {
        // validate that the name is at least 4 characters;
        // if so, return true;
        // if not, add the error with AddError() and return false
    }
}

现在，当需要验证时，请向您的 IoC 请求一个 ValidatorFor< /code> 并调用 IsValid()。

但是，当您需要更改验证逻辑时会发生什么？那么，您可以创建一个新的 ValidatorFor实现，并将其注册到 IoC 中，而不是旧的实现。但是，如果要添加另一个标准，则可以使用装饰器：

public class ProductNameMaxLengthValidatorDecorator : ValidatorFor<Person>
{
    List<IDataErrorInfo> _errors;
    public IEnumerable<IDataErrorInfo> errors 
    { 
        get
        {
            foreach(IDataErrorInfo error in _errors)
                yield return error;
        }
    }
    void AddError(IDataErrorInfo error)
    {
        if(!_errors.Contains(error)) _errors.Add(error);
    }

    ValidatorFor<Person> _inner;

    public ProductNameMaxLengthValidatorDecorator(ValidatorFor<Person> validator)
    {
        _errors = new List<IDataErrorInfo>();
        _inner = validator;
    }

    bool ExceedsMaxLength()
    {
        // validate that the name doesn't exceed the max length;
        // if it does, return false 
    }

    public bool IsValid(Product entity)
    {
        var inner_is_valid = _inner.IsValid();
        var inner_errors = _inner.errors;
        if(inner_errors.Count() > 0)
        {
            foreach(var error in inner_errors) AddError(error);
        }

        bool this_is_valid = ExceedsMaxLength();
        if(!this_is_valid)
        {
            // add the appropriate error using AddError()
        }

        return inner_is_valid && this_is_valid;
    }
}

更新 IoC 配置，现在您可以验证最小和最大长度，而无需打开任何类进行修改。您可以通过这种方式链接任意数量的装饰器。

或者，您可以为各种属性创建许多 ValidatorFor实现，然后向 IoC 请求所有此类实现并循环运行它们。

Answer 7

好吧，这是我的第三个答案，因为有很多方法可以给这只猫剥皮：

public class Product
{
    ... // normal Product stuff

    IList<Action<string, Predicate<StaffInfoViewModel>>> _validations;

    IList<string> _errors; // make sure to initialize
    IEnumerable<string> Errors { get; }

    public void AddValidation(Predicate<Product> test, string message)
    {
        _validations.Add(
            (message,test) => { if(!test(this)) _errors.Add(message); };
    }

    public bool IsValid()
    {
        foreach(var validation in _validations)
        {
            validation();
        }

        return _errors.Count() == 0;
    }
}

通过此实现，您可以向对象添加任意数量的验证器，而无需将逻辑硬编码到域实体中。不过，您确实需要使用 IoC 或至少一个基本工厂才能使其有意义。

用法如下：

var product = new Product();
product.AddValidation(p => p.Name.Length >= 4 && p.Name.Length <=20, "Name must be between 4 and 20 characters.");
product.AddValidation(p => !p.Name.Contains("widget"), "Name must not include the word 'widget'.");
product.AddValidation(p => p.Price < 0, "Price must be nonnegative.");
product.AddValidation(p => p.Price > 1, "This is a dollar store, for crying out loud!");

Answer 8

您可以使用其他验证系统。您可以在服务层向 IService 添加一个方法，例如：

IEnumerable<IIssue> Validate(T entity)
{
    if(entity.Id == null)
      yield return new Issue("error message");
}