利用通用存储库接口

Question

我见过存储库模式的各种用法。我倾向于一种我很少看到的模式，我想知道这是否有充分的理由。

        Class Teacher : IPerson
        {
            Private IRepository myRepository;

            Internal Teacher(IRepostory repo){
                This.myRepository = repo;
            }

            Public overrides void Save(){
                Repo.Save(this);
            }
        }

例子：

 IPerson p = DataAccess.GetPersonFromId(id);
 p.Name = "Bill";
 p.Save();

利益

1. 构造函数将是内部的，只能通过工厂模式访问，所以我不担心这里的复杂性。
2. IPerson 强制实现 Save（） 方法，但教师不需要知道它是如何持久化的
3. 工作原理类似于实体框架代理对象
4. 我可以在 Iperson 对象上调用 Save（），而无需知道它是老师
5. 应用-

欺骗

>

业务对象不再是普通的旧C#对象。

对实体存储库的任何更改都可能需要更改“个人”界面。

我应该对IFactory应用相同的模式吗？我们是否继续注射服务？

        IPerson p = DataAccess.GetPersonFromId(id);
        IRepostory repo = DataAccess.GetRepositority()
        p.Name = "Bill";
        repo.Save(p);

利益

1. 似乎是更简单的做事方式

欺骗

1. 我不能很好地利用可用于所有派生类型的通用存储库。我想使用一个可以采用Person Type并知道如何持久化它的Irepostory接口。

总结

我倾向于模式1，但我在那里看到的几乎每个示例都使用模式2的版本。

主要目标是我不想在应用层的任何地方使用TeacherRepository。我想完全依靠IRepository。然而，我似乎无法在模式2中做到这一点，因为Save（）需要知道它与老师的关系，才能正确地持久化数据。

有没有其他独特的模式可以让我使用通用存储库？

Answer 1

关于模式 1：它与使域对象不仅不知道底层存储类型，而且不知道它必须存储在某个地方的简单事实的原则相矛盾。更重要的是，通过应用模式 1，您打破了单一责任原则：您将有两个原因来更改域对象：业务逻辑和存储。而且，从行为的角度来看，得救不是老师的责任，而是存储库的责任。因此，恕我直言，利弊不再需要讨论。注意：并非所有框架都遵循良好的OOP设计。在大多数情况下，考虑使用活动记录的ORM。他们正在使用类似“班级教师扩展ActiveRecord”之类的东西。或者强加“每桌一课”等条件。那么，你怎么看？

关于模式 2 和您的问题：在这里，您正在尝试强制执行我上面提到的内容：以某种方式标准化数据访问工作流，以便能够存储任何类型的域对象属性和构造。对象关系映射...你可以这样做，但你必须处理很多缺点。而且，您必须考虑您的业务在业务逻辑和存储结构方面的重要性。更不用说当您必须处理具有更高复杂程度的查询时缺乏灵活性。最后 - 我听说 - 你甚至会发现有些任务实际上是不可能解决的。

因此，我的建议是让“普通旧”业务对象完全不知道存储，为它们定义特定的存储库，并从外部（例如通过服务）将它们“绑定在一起”。

实际上，存储库是在所谓的数据映射器之上的数据访问抽象层。数据映射器仅与基础数据库通信。在你的问题中，你可以在这里找到一个很好的论证：

• 数据映射器模式：类设计

这里还有一些其他的资源:

• MVC中的模型结构
• SRP公司

祝你好运.