我认为主要问题是这些方法不属于实际实体,而是应该由您的存储库服务定位器提供(好吧,它根本不必是定位器,理想情况下您只需拥有一个组合root 并通过构造函数注入所有存储库依赖项)。
但我们的想法是为 CRUD 操作提供一个通用的基础存储库接口:
public interface IRepo<T>
{
T Get(long id);
IList<T> GetAll();
void Save(T instance);
...
}
以及特定实体的特定接口:
public interface IFooRepo : IRepo<Foo>
{
// additional Foo-specific stuff, if needed
}
这允许您拥有一个通用的基础抽象实现:
public abstract class BaseRepo<T> : IRepo<T>
{
// provide default implementations for Load, Save and common stuff
}
然后您的特定存储库继承基类并可选择实现特定方法(请注意,此类不应在任何地方直接实例化,而应通过 DI 容器来实例化):
class FooRepo : BaseRepo<Foo>, IFooRepo
{
// no need to re-implement anything except Foo-specific stuff
}
最后,您有了服务定位器(免责声明:它通常用作单例,但实际上不应该如此):
// get the service locator
var repoFactory = GetRepoFactory();
// get the actual repo through DI
var repo = repoFactory.GetRepo<IFooRepo>();
// do stuff
var foo = repo.FindAll();
所以,我的主要观点是GetRepo
我最后一个代码片段中的方法不属于 POCO 实体。本文 http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application显示了使用 EF 的存储库模式的示例(跳到“实现通用存储库和工作单元类”部分),尽管我更喜欢通过 DI 将存储库注入到控制器中,而不是通过new
ed 在控制器构造函数内。