我有一个实现接口IRepository
的存储库。存储库对应用程序的实体框架(代表)执行查询,并直接返回生成的实体对象。
实施IRepository
的重点是,以便将来可以为不同的存储库切换。但是,返回实体框架返回的确切实体对象将会破坏这一点。这可以接受吗?
因此,在将所有Entity Framework对象暴露给应用程序之前,它是否应该将所有Entity Framework对象转换为业务对象?这些对象应该实现接口还是具有公共基类型?
答案 0 :(得分:11)
存储库接口应仅处理业务/域实体,即存储库仅发送和接收应用程序已知的对象,与底层持久性访问实现无关的对象。 / p>
EF或Nhibernate实体正在对域名持久性数据 NOT 进行建模。因此,IRepository不应该返回一个对象,该对象是ORM的实现细节,而是一个可以由应用程序直接使用的对象(域实体或简化视图模型,具体取决于操作)。
在存储库实现中,您将处理将映射到相应应用程序实体的ORM实体(通常使用AutoMapper等映射器)。长话短说,在设计IRepository时忘记了它的实现。这就是为什么在决定是否使用ORM之前设计界面更好的原因。
基本上,存储库是应用程序域上下文和持久性上下文之间的网关,应用程序不应该与存储库的实现细节相关联。
答案 1 :(得分:1)
您应该考虑使用其中一个POCO模板来生成实体。这样,您的实体对Entity Framework没有特殊的依赖关系,并且可以在层之间自由传递。与维护完全独立的域模型和两者之间的映射相比,它节省了大量的工作(除非您的域模型与实体模型明显不同,在这种情况下它会更有意义)。
答案 2 :(得分:0)
如果您使用的是POCO实体,您可以假设任何提供商都会执行类似的工作。另外,请记住您正在返回实体,这些实体的属性已映射到数据库。因此,您可以假设,除非实体为每个提供程序提供不同的属性名称(我找不到具有不同名称的逻辑解释),您可以直接将它们从存储库返回到业务。