architecture - 改变我们的 BL 设计——哪种模式最有用？

Question

我正在重构我们的 BI 层以使我们的代码更加“松散耦合”，我很想听听你们认为可能会做出哪些有趣的改进？

目前，我们的 API 是这样的:-

// Fetch a collection of objects
ProductCollection prods = Product.GetProducts();

// Load an individual object, make change and save it back
Product p = new Product();
if(p.Load(productID))
{
    p.Name = "New Name";
    p.Save();
}

如您所见，我们用于获取对象集合/加载单个对象和保存更改的方法都内置在“模型”类中。我们的每个模型类都继承自 ObjectBase 基类，该基类包括 DB 访问函数和更改跟踪，因此当有人通过属性更改值时，对象会自动标记为脏，并向订阅了这些事件的任何对象 (UI) 触发通知。

我想做的是使用“存储库模式”，以便我们可以将数据库实现从模型中抽象出来。但是，我一直在查看的大部分代码似乎都表明“模型”类不应该包含任何智能，而应该只是数据的容器。相反，应该通过使用服务来应用逻辑。那么这是否意味着完成上述我需要做类似的事情

List<Product> prods = ProductService.GetProducts();

Product p = ProductService.GetSingleProduct(productID);
p.Name = "New Name";

ProductService.SaveProduct(p);

这似乎是一种更复杂的方法，并且更难将功能封装在业务对象中。

有人可以解释为什么这是一种更好的方法，或者我可能误解了这些概念吗？

谢谢

詹姆斯

Answer 1

您当前的 API 是 Active Record Pattern 的实现。 .当代码中使用的对象模型与数据库模型一对一匹配时，这种模式往往可以正常工作。另一个优点是存在生成这些类的工具，包括持久性代码和数据库表。

您建议的替代方案是存储库模式。正如您已经提到的那样，实现这有点复杂，但有几个优点。由于您可以实现任何类型的 ORM 工具，因此您不仅限于一对一的映射，还可以实现更复杂的映射，其中对象模型可能与数据库模型不同。因此，您不必在数据库中强制使用对象模型或相反。然而，除了一对一之外，更复杂的映射无法生成，需要一些

另一个优点是您可以更轻松地创建测试，因为您可以创建一个甚至不需要数据库的 Mock 存储库。

使用存储库模式，您还可以将模型与持久性逻辑分开。

在这两种情况下，都可以以通用方式编写持久性方法，以便持久性代码是通用的，不需要知道需要持久化的特定对象。这对于 Active Record 模式来说是显而易见的，因为所有这些对象都实现了保存、删除、更新等。对于存储库模式，您还可以使用适用于任何对象的 ORM 工具，这样就可以编写这样的代码:

Repository.Save(ObjectOfAnyType);

ObjectOfAnyType 可以是任何东西，只要 ORM 工具为对象的类型定义/实现了一些映射。

因此，您可以选择、想要或需要这些优势，但会增加一点复杂性。或者事件记录模式的简单性就足够了。

我总是倾向于使用存储库模式，但有时也会使用 Active Record 模式，主要用于快速原型(prototype)设计。