我有一个存储库，它实现了接口IRepository。存储库对实体框架（代表）应用程序执行查询，并直接返回生成的实体对象。实体对象是否应该由存储库公开？
实施IRepository时的要点是，它可以在将来转换为不同的存储库。然而，返回实体框架返回的确切实体对象将会破坏这个。这可以接受吗？
因此，存储库是否应该将所有实体框架对象转换为业务对象，然后再将其暴露给应用程序？这些对象应该实现一个接口还是具有一个通用的基类？
存储库接口应该只处理业务/域实体，即存储库只发送和接收应用程序已知的对象，与底层持久存取实现无关的对象。
EF或Nhibernate实体正在建模持久性数据而不是域的。因此，IRepository不应该返回一个对象，该对象是ORM的实现细节，而是可以直接由应用程序使用的对象（根据操作可以是域实体或简化的视图模型）。
在存储库实现中，您将处理将映射到相应应用实体（通常使用映射器（如AutoMapper））的ORM实体。长话短说，设计IRepository时忘记了它的实现。这就是为什么在决定是否使用ORM之前设计界面更好。
基本上，存储库是应用程序域上下文和persitence上下文之间的网关，应用程序不应该耦合到存储库的实现细节。
+1确认我问这个问题的原因 – 2012-03-22 13:51:51
你应该看看使用其中一个POCO模板来生成实体。这样你的实体对Entity Framework没有特别的依赖关系，并且可以在层间自由传递。与维护一个完全独立的领域模型和两者之间的映射（除非你的领域模型与你的实体模型明显不同，在这种情况下它会更有意义）相比，它节省了大量的工作量。
如果您使用的是POCO实体，您可以假设任何提供者都会执行类似的工作。另外，请记住，您正在返回的实体的属性映射到数据库。所以你可以假设除非实体对每个提供者有不同的属性名称（我找不到具有不同名称的逻辑解释），你可以直接从存储库返回它们的业务。
你想支持什么'不同的存储库'。你的意思是从EF切换到NHibernate？如果是这样的话，你可能会比IRepository接口产生更多的变化。 – 2012-03-22 12:40:12
我并没有特别想到任何东西，但我希望我的应用程序更健壮。你在想什么其他的改变？ – 2012-03-22 12:44:46