EF4 complex Select (): returns IEnumerable or IEnumerable <MyCustomDto> from the business layer?

Question

I started a new job in which we port a fairly large VB.NET 2.0 application (with datasets) to C # 4.5 (with EF4.)

From our business layer, our Search functions now return IEnumerables of the classes defined in our EDMX. So something like this is simple:

public IEnumerable<Product> GetProductsByCategory(int categoryId) 

But this is more complicated when our EF4 "Select ()" method creates a more complex, customized (anonymous) type: the generated class is not created that matches the result.

Since this function should cross the boundary of the level (Business to UI), I thought that the appropriate solution would be to define a custom type for this request, and then return an IEnumerable of this type; eg.

 public IEnumerable<ProductAccountSummary> GetProductAccountSummariesByCategory(int categoryId) 

where ProductAccountSummary is a DTO with manual processing (i.e. POCO).

However, while checking the code, the team leader was unable to follow my approach; he asked me to remove the DTO and change the method signature to:

 public IEnumerable GetProductAccountSummariesByCategory(int categoryId) 

.... The reason is that we can still bind IEnumerable to our user interface networks, etc. without the overhead of manually developing a DTO every time we need to use a custom type.

So my question is:

• In EF4, what is the typical approach for passing collections of user types across level boundaries? The return of IEnumerable (implicitly, an “object”) just doesn't seem right to me. Did I miss something?

Answer 1

I think your team is simply mistaken. Working with strongly typed objects is usually seen as a way to do something. Using this approach, you are again working in the world with types such as a dataset. There will be a headache for long-term maintenance when it becomes necessary to change facilities and transfer them back to the business level. There will even be a headache for customer service, even if nothing needs to be returned to the business level.

Yes, there is overhead for creating a DTO, but short-term speed should not be the reason used for possible long-term maintenance problems.