设计问题 POCO 对象/DAL 访问

Question

我想实现典型的三层架构。我当前的方法如下所示：

• DAL - 使用 EF 4.0 和每个实体的存储库。通过接口访问
• 我正在考虑使用 POCO 对象。我的第一个问题是我应该把它们放在哪里 文件？在所有其他项目引用的程序集中？
• BLL - 如何将数据从 DAL 获取到 BLL，然后最终获取到 GUI 如果我在 BLL 中拥有一大堆管理器类（例如 CustomerManager），这是一个好方法吗？这些类将访问 BLL 中相应的存储库，然后将对象传递给 GUI

或者您认为最好将存储库放在 BLL 中并直接从我所说的 ButtonEventHandler 访问它们？

希望你能为黑暗带来一丝光明

Answer 1

我们在 DAL 中有存储库。 BLL 通过接口引用存储库 - 因此存储库绑定到 DAL，但与 BLL 解耦。我不知道存储库不能直接位于 BLL 中的任何原因。我们将它们放在 DAL 中，因为我们没有在其中放入任何逻辑。然后，我们在 BLL 中有“管理器”，它包装存储库并处理特定于实体的逻辑。

FWIW 实际上我们有一个通用的 Repository(Of IEntity) 并使用 unity 根据需要实例化适当的存储库 - 它非常紧凑且非常优雅。我们所有的 POCO 实体都实现 IEntity，其中包含我们所有实体所共有的 Id、CreatedDate 等。当您需要一般处理任何类型的实体时，这会带来一些其他好处 - CreatedDate 是在调用 CreateInstance() 时由存储库设置的，ModifiedDate 是由存储库设置的> 当提交状态为“已修改”的实体时，由上下文本身设置。

我们将实体保存在单独的项目中 - DAL 需要能够引用它们，BLL 也是如此。您不希望它们出现在 DAL 中，因为换出 DAL 会导致问题。您不能将它们放入 BLL 中，否则会出现循环引用。实体的配置可以存在于 DAL 中，因为它是特定于数据源的。

我们尝试坚持采用 BLL 接收原语并返回实体。请注意不要将实体在 UI 中保留太长时间，尤其是在 Web 应用程序中，因为当您将实体返回到 BLL 进行处理时（即跨存储在会话或类似内容中的请求），DAL 下可能会出现不同的上下文。可能会导致各种有趣的从上下文中附加/分离实体的过程，并失去一些好处，例如更改跟踪。

希望有帮助，但如果您需要任何说明，请告诉我

Answer 2

这是我们的设置：

Company.Project.Domain.Model      (POCOs)
Company.Project.Business.Services (BLL)
Company.Project.Data.Repositories (Repository)
Company.Project.Web               (Presentation)

• POCO 位于其自己的组件中。 没有引用任何内容，并且被所有人引用。
• BLL 对存储库执行查询、应用业务规则和水合作用。 返回 ICollection 或 T。 参考存储库（通过 IRepository 通用接口）和 POCO。
• Repository 是一组实现 IRepository的通用类，以提供针对底层存储的基本持久性。查找、添加、删除等。返回IQueryable。 参考 POCO，参考 BLL。
• 演示是 UI。 参考 POCO 和 BLL。

最终结果是类似堆栈的方法，并且因为基本上一切都是通过接口（和 DI 注册表）进行的，所以灵活性是巨大的。

我们有通过 DI 注入到测试项目中的模拟存储库，以及通过 DI 注入到 BLL 中的实体框架存储库。

UI 中的示例流程 -> DB：

// "Company.Project.Web.ProductsController.cs"
public class ProductsController : BaseController
{
   private IProductService _productService;

   public ProductsController(IProductService productService)
   {
      this._productService = productService; // DI makes me happy :)
   }

   public ActionResult GetOrdersForProduct(Product product)
   {
      var orders = _productService.GetOrders(product);
      return View(orders);
   }
}

// "Company.Project.Business.Services.ProductService.cs"
public class ProductService : IProductService
{
   private IRepository<Product> _productRepository;

   public ProductService (IRepository<Product> productRepository)
   {
      this._productRepository = productRepository; // DI makes me happy :)
   }

   public ICollection<Orders> GetOrdersForProduct(Product product)
   {
      return _productRepository
                .Find()
                .ForProduct(product) // IQueryable<Product> pipe/extension filter
                .ToList();
   }
}

// "Company.Project.Data.Repositories.GenericRepository.cs
public class GenericRepository<T> : IRepository<T> where T : class
{
   private IObjectSet<T> _objectSet;

   public GenericRepository(IUnitOfWork unitOfWork)
   {
      CurrentContext = unitOfWork as SqlServerUnitOfWork;
   }

   public IQueryable<T> Find()
   {
      return CurrentContext.GetEntitySet<T>();
   }

   protected SqlServerUnitOfWork CurrentContext { get; private set; }

   protected IObjectSet<T> CurrentEntitySet
   {
      // some plularization smarts in "SqlServerUnitofWork.cs", to dynamically pull
      // back entity set based on T.
      get { return _objectSet ?? (_objectSet = CurrentContext.GetEntitySet<T>()); }
   }
}

如你所见，我是 DI 的粉丝。

Answer 3

您可以通过将存储库和 POCO 保留在同一个项目中来保持这一点非常简单。这本质上就是您的数据域模型。您的 POCO 是公共的，您的存储库接口也是公共的。您应该将具体存储库保留在该项目内部。

您的 BLL 可以是经典的外观或服务定位器。该项目将处理您的数据并应用任何相关的业务规则，然后再将其移交给 UI。它还负责在将数据发送到 DAL 之前验证来自 UI 的数据。