Is LINQ Multi Layered?
Several weeks ago, we discussed the point of Multi-Layered Architectures. We discussed what a multi-layered architecture looks like, and the problems it solves.
Today, what I want to examine is the question, “Is the LINQ model we’ve been looking at since then really multi-layered?”
So, the first thing we should examine is obviously, does it look multi layered on the surface? I guess that really depends on how you look at LINQ. My first tendancy was to view the LINQ to SQL classes and the extension points as two different layers.
But, on closer inspection, I think what we really have is this:
To a large extent, it is the attributes of the LINQ 2 SQL classes that are controlling the access to the database. The methods are the conduit between the presentation layer and the data access layer.
So, yes, it looks multi-layered.
So, does it meet the other criteria we setup? Does this model solve all of the problems?
- Does it keep business logic out of the presentation layer?
Well, it almost does this? If you ask me, Microsoft has a pretty funky implementation for using a SELECT stored procedure that pretty well forces the call into the presentation layer. Further, you could add filtering code in the event handler that would force more BLL code into the presentation layer. The SELECT method would have been better implemented like the INSERT/UPDATE/DELETE methods in the LINQ 2 SQL classes.
- Does the DAL only have code in it that gets data out of the database?
Yes, since Microsoft is doing all of this for us via the attributes, this is pretty well separated.
- Does the BLL allow us to validate our data on the way down to the database?
Yes, this has been well implemented via the extension points.
- Does the BLL allow us to translate our data as we move it from the DAL to the View and back again.
Yes, again, this is allowed by using extension points.
- Can we swap out the presentation layer?
Yes, we should be able to do this without much trouble.
- Can we swap out the DAL?
No, LINQ 2 SQL is pretty well tied to MS-SQL.
- Can we place each of the layers on different computers?
No, but this does not mean it is not multi-layered. It only means that we can’t use it in a mult-tiered implementation. The ideal would be for it to do both.
So, we have one place in LINQ 2 SQL where it fails true multi-layered capabilities and another nice to have that we’ve lost.
Does it matter?
If all you are building is web sites that use MS-SQL for the database, it probably doesn’t matter. While I would not call this a multi-layered architecture, it is a functional architecture for building web applications that don’t have a completely unorganized mismatch of code that no one would know how to maintain if they were not the ones who had written it.
However, if you are planning to use the same code base for web applications and other applications, like windows forms, or you need this to work with multiple databases, you may need to provide a few tweaks to this model so that it will work for you, instead of against you.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
