一直在忙着创建一个新的应用程序,基本上我有我的dataccess,服务层和表示层...一切都很好但我使用EF返回的实体类。这里的问题是我将这些传递到表示层,所以我需要将实体框架引用/ dataccess添加到表示层 - 不好:
所以我的想法如下,并且正在寻找一些帮助和确认,我将走向正确的路线......
在服务层中创建一组类,如客户,订单等,因为表示层具有对服务层的引用。
当在dataccess中返回一个客户实体时,我会将实体类即Customer返回给服务,我会在这里进行映射 - 不太确定我喜欢这个吗?
哪里是我用于映射的这些“标准类”的最佳位置,如果我将它们放在服务层并对dataaccess进行映射,那么这将创建一个循环引用作为Dataccess>服务和服务> dataaccess .. - 它应该只有一种方式,即服务>数据访问
我正在考虑使用Automapper(http://www.codeplex.com/AutoMapper)来处理这个问题,我是否在正确的路线上?任何想法或例子都非常赞赏..
正如我所说,唯一的事情就是当我从dataaccess返回到服务层(使用Iqueryable)时,我需要将它们从实体类中映射出来并使用标准集合类。
我认为这是我感到困惑的地方,我觉得使用实体类并不好,因为这意味着我需要在表示层中引用实体框架/ dataaccess才能访问实体类。
答案 0 :(得分:3)
你已经遇到了EF v1的一个弱点。现在,是的,使用AutoMapper进行路线肯定允许您将EF实体转换为“直接”业务实体并在更高层中使用它们。
此外,应用于.NET 4.0 / Visual Studio 2010的EF v4应该会在许多问题领域带来很多缓解 - 支持您自己的直接POCO(普通旧CLR对象)以及更多。查看EF Design Blog。关于EF v4,该团队最近发布了一些非常有趣,非常有前途的帖子。我很期待它!
马克
答案 1 :(得分:0)
如果将接口提取到核心/公共项目中并从Web项目使用的存储库或服务中返回接口类型,则可以在Web项目中使用EF对象。 您可以通过创建部分类并在那里添加来使EF对象实现您的接口:
partial class Customer:ICustomer
即使您可以执行1.技巧,您仍然应该使用automapper将这些实体映射到适合您特定视图的自定义ViewModel对象。您还可以使存储库/服务的查询方法直接返回DTO / ViewModels - 它有时可以使查询更有效(仅查询所需的列等),但这需要额外的EF映射。