c# - EF4 复杂的 Select() : Return IEnumerable or IEnumerable<MyCustomDto> from Business Tier?

标签 c# entity-framework-4 anonymous-types business-logic-layer ef-database-first

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

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

public IEnumerable<Product> GetProductsByCategory(int categoryId)

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

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

public IEnumerable<ProductAccountSummary> GetProductAccountSummariesByCategory(int categoryId)

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

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

public IEnumerable GetProductAccountSummariesByCategory(int categoryId)

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

所以我的问题是:

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

最佳答案

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

是的,创建 DTO 会产生开销,但短期速度不应成为导致最终长期维护问题的原因。

关于c# - EF4 复杂的 Select() : Return IEnumerable or IEnumerable<MyCustomDto> from Business Tier?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13215633/

相关文章:

c# - 使用 Unity 的 Web Api 核心项目

Javascript 调用在文本框更改时具有旧值

c# - ServiceStack .NET Core 的 OAuth2 身份验证插件

C# MongoDB bulk Upsert - 批量写入操作导致一个或多个错误

wcf - EDM -> POCO -> WCF (.NET4) 但是传输集合会导致 IsReadOnly 设置为 TRUE

java - 在匿名对象上调用父类(super class)方法 AsyncTask.execute() new HttpRequestTask<...> extends AsyncTask<...>

c# - 如何处理匿名类型 <T> 的强制转换委托(delegate),委托(delegate) T 以便在 IEnumerable<T> 的Where<T>() 方法中使用

c# - 应用当前值时 Entity Framework 更新问题

visual-studio - 如何创建 Entity Framework 项目?

c# - 将 linq 中的 select 子句组合到具有匿名类型的实体