LINQ for n-Tier Architecture Part 2


I’ve had the opportunity to explore different approaches to building an n-tier application with LINQ to SQL for a few months and working out the details of what has to be done with different approaches. I’ve tried the approach of propagating LINQ entities from the DAL to the UI and back, using the Repository pattern to handle entities and my current favourite approach: using DTOs.

Propagating the LINQ entities up the UI layer and back posed several problems:

  • “Fat” objects going to the UI and impacting performance and scalability
  • Handling associations (foreign key references) was difficult to say the least. I found the process of detaching and reattaching LINQ entities to be fairly painful and my final solution was far from satisfactory in terms of elegance and maintenance.

The use of the Repository pattern likewise had a few problems:

  • The data context is scoped at the level of a HttpRequest, prohibiting multi-screen transactions
  • Bloated object graph – you naturally would be bringing back the actual LINQ entities to the UI and potentially bringing back a large number of referenced objects.

Using DTO:

  • Required the construction of lightweight DTOs (yes, hand-coded DTOs). These have the advantage of being easily serializable to travel over a web service.
  • The use of assemblers to handle the hydration of DTOs and the injecting of data back to the database
  • Many DTOs mean many assemblers

While every person may have their individual preferences, my preference is to use the DTO approach. After coding my fifth assembler, I decided that enough is enough. Using Reflection, I created a generic assembler that is used to hydrate and extract data from DTOs. I was initially concerned with any performance issues but the result of using reflection has a minimal performance hit. What I’ve found with DTOs is that while it might seem that there’s additional overhead in creating these objects, it literally does not take more than a few minutes at most to build one. The DTOs allow me to limit the scope of data which I am bringing to the UI, which effectively means that I only bring what I need to the UI and avoid bringing bloated objects to the UI.

With the official release of the ADO.NET Entity Framework today in .NET 3.5 SP1, I’m eager to see how the approach to building n-tier applications with OR\Ms may change.

Technorati Tags: ,,

No Responses Yet to “LINQ for n-Tier Architecture Part 2”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: