存储库是否应公开实体对象
本文关键字：实体 对象 是否 存储 | 更新日期: 2023-09-27 18:28:44
我有一个实现接口IRepository的存储库。存储库（代表）对应用程序的实体框架执行查询，并直接返回生成的实体对象。
实现IRepository的全部目的是为了将来可以将其切换到不同的存储库。然而，返回实体框架返回的确切实体对象将打破这一局面。这可以接受吗？
因此，在将所有实体框架对象公开给应用程序之前，存储库是否应该将其转换为业务对象？这样的对象应该实现一个接口还是有一个公共的基类型？
存储库接口应该只处理业务/域实体，也就是说，存储库只发送和接收应用程序已知的对象，这些对象与底层的永久访问实现无关。
EF或Nhibernate实体正在建模持久性数据而不是域数据。因此，IRepository不应返回作为ORM实现细节的对象，而是可以由应用程序直接使用的对象（根据操作，可以是域实体，也可以是简化视图模型）。
在存储库实现中，您处理ORM实体，这些实体将被映射到相应的应用程序实体（通常使用诸如AutoMapper之类的映射器）。长话短说，当设计IRepository时，忘记了它的实现。这就是为什么在决定是否使用ORM之前最好先设计接口。
基本上，存储库是应用程序域上下文和持久性上下文之间的网关，应用程序不应与存储库的实现细节耦合。
您应该考虑使用其中一个POCO模板来生成实体。这样，您的实体对实体框架没有特殊的依赖关系，并且可以在层之间自由传递。与维护一个完全独立的域模型和两者之间的映射相比，它节省了大量的精力（除非你的域模型与实体模型有很大不同，在这种情况下它会更有意义）。
如果您使用POCO实体，您可以假设任何提供者都会做类似的工作。另外，请记住，您正在返回实体，这些实体的属性已映射到数据库。因此，您可以假设，除非实体对每个提供者具有不同的属性名称（我找不到具有不同名称的逻辑解释），否则您可以直接将它们从存储库返回到业务。