EF4 complex Select(): Return IEnumerable or IEnumerable<MyCustomDto> from Business Tier?

Question

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?

Answer 1

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.