Home/ Questions/Q 8789375
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T22:23:19+00:00

I’ve started a new job in which we’re migrating a reasonably large VB.NET 2.0

  • 0

I’ve started a new job in which we’re migrating a reasonably large VB.NET 2.0 app (with datasets) to C# 4.5 (with EF4.)

From our business layer, our “Search” functions are now returning IEnumerables of the classes defined in our EDMX. So something like this is straightforward:

public IEnumerable<Product> GetProductsByCategory(int categoryId)

But it is more complicated when our EF4 “Select()” method is producing a more complex, customised (anonymous) type: there is no generated class corresponding to the result.

Because this function has to cross the tier boundary (Business to UI), I had thought that the appropriate solution would be to define a custom type for this query and then return an IEnumerable of that type; e.g.

public IEnumerable<ProductAccountSummary> GetProductAccountSummariesByCategory(int categoryId)

where ProductAccountSummary is a hand-crafted DTO (i.e. POCO).

However, during code review, the Team Lead failed my approach; he’s asked me to delete the DTO and change the method signature to:

public IEnumerable GetProductAccountSummariesByCategory(int categoryId)

….The reason being that we can still bind the IEnumerable to our UI grids etc. without the overhead of hand-crafting a DTO every time we need to use a custom type.

So my question is:

  • In EF4, what’s the typical approach for passing collections of custom types across tier boundaries? Returning an IEnumerable (implicitly, of “object”) just doesn’t seem right to me. Am I missing something?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think your team lead is simply wrong. Dealing with strongly-typed objects is generally viewed as the way to do things. Using this approach, you’re back in the world of working with types like dataset again. There will be a long-term maintenance headache when it starts to become necessary to modify the objects and pass them back to the business layer. There will even be a maintenance headache on the client side even if nothing needs to be returned to the business layer.

    Yes, there is overhead with creating DTOs, but short-term speed shouldn’t be the reason used for eventual long-term maintenance issues.

    • 0