LINQ for n-Tier Architecture


It’s been a while since I last updated my blog. The reason for that is mainly work commitments and also time needed to explore different approaches to incorporating LINQ in an n-tier application.

I’ve tried several different approaches for an ASP.NET environment. The stateless nature of the application forced me to come up with different strategies for handling the data context (or unit of work). I tried instantiating LINQ custom entities and then detaching them from the data context and passing it to the UI. That works for perhaps more than half the scenarios but it really does not work well when you need to reference a related entity. The fact that the custom entity is detached means that it has no data context to reference any related entities and it really showed its shortcomings in multi-screen transactions where data comes from several entities.

I mentioned it to some former colleagues of mine (you know who you are) and they mentioned a different way of handling LINQ entities. One worked with NHibernate and the other one with LINQ and the strategy they come up with was remarkably similar. Basically, by creating lightweight data transfer objects or DTOs which are hydrated from LINQ entities. These objects will contain enough information to populate controls on a page and later are used to encapsulate data which should be sent back to the database.

At first, this approach really didn’t sit well with me. I thought that it was not much better than getting a dataset back from the database, hydrating some custom objects and passing them on. I was quite wrong, though. This strategy worked beautifully from the perspective of using LINQ to interact with the database. The DTOs were simple to write and where they really excelled at was “flattening” of data from related entities. They really shone for containing data that spanned different entities!

Yes, there is a degree of duplication using this method. You will have to write code for property assignment and extraction but the beauty of it is that it is very simple code and hardly takes any time to write. The more I used this method, the more I grew to like it. It provide simplicity and a fairly clean way of incorporating LINQ. I will post more on this architecture later once I get a bit more time.

I’d like to thank Paul and Malcolm for their feedback. It was inspirational and extremely helpful.


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

  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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: