使用管理器类作为单例可以吗？
对于每个具体类，我都有一个 Manager 类。这个类有诸如GetAll()、GetById()、Save等方法。
我已经将这些管理器类设置为单例，因为我总是需要一个实例，并且我有能力缓存结果。例如，当我调用 GetAll() 时，下次再次需要此方法时，管理器不必访问数据库，它可以返回缓存的结果。
这是一个好方法吗？或者有更好的替代方法吗？
For each concrete class I have a Manager class. This class has methods like GetAll(), GetById(), Save, etc.
I've made these manager classes a Singleton because I always need one instance, and I have the ability to cache results. For example, when I call GetAll() and the next time I need this method again, the manager don't have to go to the database, it can return the cached results.
Is this a good approach? Or is there a better alternative way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您所说的管理器类实际上是“存储库”。
存储库应该仅在聚合根级别上工作，而不是每个类一个存储库。例如，如果我有一个 Order 类，其中包含 OrderItem 的集合，那么将存在一个具有 Get/GetAll 方法的 Order 存储库 - 因为在本例中 Order 是聚合根。
所有存储库类通常都是单例类，您通常可以通过 IOC 容器轻松地强制执行此操作。
总的来说，我想说每个实体一个“存储库”的方法是不好的 - 相反，坚持每个聚合根一个存储库。
What you call manager classes are really "repositories"
Repositories should only work at an aggregate root level, not one repository per class. E.g. if I have an Order class which has a collection of OrderItem, then an Order repository would exist that would have Get/GetAll methods - as the Order is the agg root in this case.
All repository classes would usually be singleton classes, where you can usually enforce this easily via an IOC container.
Overall, I would say your approach of one "repository" per entity is bad - stick to one repository per aggregate root instead.
为什么不将它们作为具体类的一部分而不是静态的呢？节省了对两个单独类的需要。
Why not include them as part of the concrete class but static? Saves the need for two seperate classes.
听起来您即将实现 存储库 模式，但并非完全如此。我建议调查一下。我不会让它们成为单例——这使得在单元测试中模拟它们变得太困难，所以你最终会添加后门来击败单例进行测试。缓存可以创建一个很好的单例对象，但是为什么不简单地以这种方式共享缓存而不是乘以单例呢？
It sounds like you are close to implementing the Repository pattern, but not quite all the way there. I'd suggest looking into it. I wouldn't make them Singletons -- it makes it too hard to mock them out for your unit tests so you end up adding back doors to defeat the Singleton for testing. A cache makes a nice Singleton object, but why not simply share the cache this way instead of multiplying Singletons?
出于测试/模拟的目的，我建议不要使用管理器/存储库单例。
如果您确实想缓存结果，那么我建议委托给专用的 Cache 类。任何静态魔法都可以包含在 Cache 类中，并且您的管理器/存储库的语义可以保持干净。
从单一职责原则的角度来看，我应该能够理解管理器/存储库的工作原理，而不必了解您的缓存方案。
For testing/mocking purposes, I would advise against using a Manager/Repository Singleton.
If you do want to cache results, then I would suggest delegating to a dedicated Cache class. Any static magic can be contained within the Cache class and your Manager/Repository's semantics can be kept clean.
From a Single Responsibility Principle point of view, I should be able to understand how a Manager/Repository works without having to understand your caching scheme.