我正在使用存储库设计与Web应用程序（存储库（数据层）公开模型（对象）到业务层，然后将其用于数据层（ui）。对象或对象列表在层之间传递这种类型的实施。
我发现我的业务层是一系列管理器类型，它们都有常见的GetAll，GetById，Save，Delete类型方法。这对于许多非常小的简单对象来说非常常见。这是一个值得关注的领域或改进的机会（一系列较小的业务经理类）。我正在寻找选项来避免整个系列的小型业务经理类映射到只有get / save / delete对象的较小对象。
除了get / save / delete类型方法之外，更接近应用程序功能的更大对象有许多方法（这些管理器类都可以）。
我在想有一个设计模式或实现，它允许我有一个驻留在业务层的管理器类，它将接受一个对象作为特定对象类型的参数和get / save / delete方法知道要旋转的存储库对象的类型，并将对象传递给它以进行操作。
这里的好处是我可以使用一个通用管理器类将较小类型对象的save / delete / get传递给适当的存储库类，从而减少许多较小的管理器类。
如何实现这一目标的想法？ THX
答案 0 :(得分：3)
我不会这样。业务层类可以像转发到数据层的代码一样简单，并且它们可能会令人讨厌，但它们存在的原因有两个：验证，安全性，根据业务规则采取某些操作。
如果您尝试创建通用业务层，则很难包含业务类可以执行的所有各种操作。通用业务层将变得比您当前拥有的层复杂得多。测试将更加困难。添加新的业务规则也很难。
很抱歉，这不是您想要阅读的内容，但我已经走了通用系统的路线，并且总是有很多遗憾。
答案 1 :(得分：0)
存储库（或dao）背后的想法是进一步从业务层中抽象出数据访问问题，以简化这些层关注给定域的“业务”。
也就是说，是许多常见的管道类型的关注点，可以在不同的应用程序中重用，其中一些确实适用于业务层中的超类型。考虑能够通过数据库中的某个Id检索给定业务实体的交叉问题，并且可能得出的结论是它实际上有用业务层超类型中的Id属性。如果实体在确定平等时认为Id，则甚至可能有用。等。
现在我确实认为Timores是正确的，并试图编写一个适合所有领域的应用程序既令人难以置信的痛苦又完全没有结果，但我也相信专业的艺术是知道如何使用各种工具何时应用哪一个，并且有一些核心基础设施代码应该在你的工具带中。
为了对已经过路试的网络应用程序的框架概念有所了解，请查看SharpArch。
HTH，
Berryl