Initial thoughts on Linq

Thoughts on Linq, and the separation between the business logic and data access layers

Initial thoughts on Linq

So I decided to join the 21st century, and being looking into other storage media, other than SQL Server.  My first inclination was to explore the different ways I could use XML to replace some functionality that I used to use SQL Server for.

After delving into classes that .Net provides for interacting with XML, I kept running into Linq references.  Being a DBA by trade, I obviously had heard about Linq, and knew about the way I know about other concepts that become buzzwords in the technology universe:  that is to say, I knew it was a data access medium.

But trying to push myself into a new mentality where I value exploration and growth over atrophy, I decided to dig into Linq a bit, and after a couple weeks of analysis, I've decided that Linq will take the place of a lot of my prior references to SQL calls.

Not being aware of the evolution of the Entity framework, and the intention, my take on Linq is that it fuses the business logic layer and the data access layer.  Consider the below example:

public void LoadObject() { _containerDataTable = _dAL.GetQueryResultsAsDataTable("SELECT * FROM [table] WHERE id='" + this.ID + "'"); }

In this example, my data access layer gives a DataTable to the LoadObject() method (which is in my business logic layer).  The above code explicitly separates the two layers, passing in a simple string to the data access layer, and returning  the intermediary, a System.Data.DataTable object.

With Linq, consider the notion of querying a XML file:

public void SomeMethod() { XmlTextReader textReader = new XmlTextReader("c:\\xmldata.xml"); textReader.Read(); XElement ajobs = XElement.Load(textReader); var jobCollection = from abc in ajobs.Descendants("Job") select abc; }

In the Linq example above, I essentially have an IEnumerable jobCollection that was populated by (what appears to be) some version of a Lambda expression.  What I don't have is the simple ability to easily decouple the business logic from the data access layer.

Obviously, I could build an engine that would allow a more distinct separation of the business logic and data access layer, but I'm not sure there is a need to do that.

So I guess I don't have any strong assertions to make in this blog, except to say that I think Linq is a really powerful tool that solves a lot of problems that used to be much heavier to solve.