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

我正在尝试为我的大型 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 应该能够隔离所有这些。

提前致谢！

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

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

为了解耦所有这些，我使用所谓的接口层。最后我有

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

这非常方便，并且创建了一个很好的解耦架构。基本上，您的表示层仅访问接口，而不访问实现本身。为了创建相应的实例，您应该使用工厂或最好使用一些依赖注入库（Unity http://www.codeplex.com/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);
   }

   ...
}

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