EF4 complex Select():从业务层返回 IEnumerable 或 IEnumerable<MyCustomDto>?

Posted

技术标签:

【中文标题】EF4 complex Select():从业务层返回 IEnumerable 或 IEnumerable<MyCustomDto>?【英文标题】:EF4 complex Select(): Return IEnumerable or IEnumerable<MyCustomDto> from Business Tier? 【发布时间】:2012-10-24 07:35:36 【问题描述】:

我开始了一项新工作,我们正在将一个相当大的 VB.NET 2.0 应用程序(带有数据集)迁移到 C# 4.5(带有 EF4)。

从我们的业务层,我们的“搜索”函数现在返回 EDMX 中定义的类的 IEnumerables。所以这样的事情很简单:

public IEnumerable<Product> GetProductsByCategory(int categoryId)

但是,当我们的 EF4“Select()”方法生成更复杂的自定义(匿名)类型时,情况会更加复杂:没有生成的类对应于结果。

因为这个函数必须跨越层边界(业务到 UI),所以我认为适当的解决方案是为此查询定义一个自定义类型,然后返回该类型的 IEnumerable;例如

public IEnumerable<ProductAccountSummary> GetProductAccountSummariesByCategory(int categoryId)

其中ProductAccountSummary 是手工制作的 DTO(即 POCO)。

但是,在代码审查期间,团队负责人未能通过我的方法;他让我删除 DTO 并将方法签名更改为:

public IEnumerable GetProductAccountSummariesByCategory(int categoryId)

....原因是我们仍然可以将 IEnumerable 绑定到我们的 UI 网格等,而无需在每次需要使用自定义类型时手工制作 DTO。

所以我的问题是:

在 EF4 中,跨层边界传递自定义类型集合的典型方法是什么?返回一个 IEnumerable (隐含地,“对象”)对我来说似乎不正确。我错过了什么吗?

【问题讨论】:

好问题。我总是在应用层之间使用 DTO。不知道为什么有人会选择非通用IEnumerable 没有评论的“-1”?残酷的!必须是我的团队负责人:) 【参考方案1】:

我认为你的团队领导完全是错误的。处理强类型对象通常被视为做事的方式。使用这种方法,您又回到了使用数据集等类型的世界。当开始有必要修改对象并将它们传递回业务层时,将会有一个长期的维护难题。即使不需要向业务层返回任何内容,客户端甚至也会出现维护问题。

是的,创建 DTO 存在开销,但短期速度不应成为最终长期维护问题的原因。

【讨论】:

以上是关于EF4 complex Select():从业务层返回 IEnumerable 或 IEnumerable<MyCustomDto>?的主要内容,如果未能解决你的问题,请参考以下文章

EF4 - 选定的存储过程不返回任何列

如何在 n 层分层应用程序中使用 Entity Framework(4) 编译查询?

N-Tier - 插入与更新的责任位置

DAL 层:EF 4.0 或带有存储过程的普通数据访问层

如何将对象类型从业务层传递到数据层

EF4 连接问题