使用 c# 使用存储库模式进行通用业务层设计（如何）

Question

我正在使用带有 Web 应用程序的存储库设计（存储库（数据层）将模型（对象）暴露给业务层，然后将其用于数据层 (ui)。对象或对象列表在层之间传递这种类型的实现。

我发现我的业务层正在成为一系列管理器类型类，它们都有通用的 GetAll、GetById、Save、Delete 类型方法。这在许多非常小的简单对象中很常见。这是关注的领域或改进的机会（一系列较小的业务经理课程）。我正在寻找避免将整个系列的较小业务管理器类映射到仅执行获取/保存/删除对象的较小对象的选项。

更接近应用程序功能的较大对象除了 get/save/delete 类型的方法外还有许多方法（这些管理器类都可以）。

我认为有一种设计模式或实现将允许我拥有一个驻留在业务层中的管理器类，该管理器类将分别接受一个对象作为特定对象类型的参数和 get/save/delete 方法知道要启动的存储库对象的类型并将对象传递给它以进行操作。

这里的好处是我可以拥有一个通用管理器类来将较小类型对象的保存/删除/获取传递给适当的存储库类，从而减少许多较小的管理器类。

关于如何实现这一点的想法？ 谢谢

Answer 1

我不会那样做。业务层类可以像转发到数据层的代码一样简单，编写它们确实很烦人，但它们的存在有几个原因：验证、安全性、根据业务规则采取一些行动。

如果您尝试创建一个通用的业务层，将很难包含一个业务类可以做的所有各种事情。通用业务层将变得比您当前拥有的要复杂得多。测试会困难得多。添加新的业务规则也很困难。

对不起，这不是你想看的，但我已经走泛型系统的路线，一直有很多遗憾。

Answer 2

存储库（或 dao）背后的想法是进一步将数据访问问题从业务层抽象出来，以简化那些专注于给定域的“业务”的层。

也就是说，有许多常见的管道类型的关注点可以跨不同的应用程序重用，其中一些确实适合业务层中的超类型。考虑能够通过某个 Id 从数据库中检索给定业务实体的横切关注点，您可能会得出这样的结论：实际上有用业务层超类型中的 Id 属性。如果实体在确定相等性时考虑该 Id，它甚至可能很有用。等等。

现在我确实相信 Timores 原则上是正确的，尝试编写一个适合所有领域的应用程序既令人难以置信的痛苦又完全徒劳无功，但我也相信该专业的艺术在于知道如何使用各种工具以及何时应用哪一个，并在您的工具带中包含一些核心基础架构代码。

如需了解经过道路测试的网络应用的框架概念，请查看SharpArch。

HTH，
浆果