I've to admit that sometimes I need times to understand a new concept,
expecially when my mind is full of other things.
One of the concept that in these days I've tryed to understand is certainly
LINQ (one
of the coolest news that comes out from the last PDC) and this post comes after
lots of time from the LINQ announce because I always need times to think...
LINQ, alias .Net Language
Integrated Query is a new technology that will add query capabilities
directly into the CLR. As a result, you will be able to use your standard
programming language (such as C# or VB.NET) and you will be able to launch
queries on data directly from within your code.
This sounds cool to me expecially after the example provided at the PDC,
where the team involved on the project showed a code that list all the
processes running on a computer which consume more than 4 MB. The code is this:
ProcessDescriptionDb db = new ProcessDescriptionDb();
var query =
from p in Process.Getprocesses()
where p.WorkingSet > 1024 * 1024 * 4
orderby p.WorkingSet descending
select new {
p.ProcessName,
p.WorkingSet
Description = (
Fom d in db.processDescriptions
Where d.processName = p.ProcessName
Select d.Description
)
};
foreach (var item in query)
Console.Writeline("{0,-30}{1,10:N0} {2}", item.ProcessName, item.WorkingSet, item.Description);
As you can see, you have the power to launch something like a SQL query on a
recordset of data that you have and this is undoubtely powerful.
But now I've some doubt about it, expecially after seeing lots of sceptic
posts... Is this power to write queries directly into the code always
powerful or (expecially on data-driven applications) it could be a
bottleneck?
I remember that when I've started to build large data-driven applications
with .NET, one of the first rules I've learned was to separate the code from the
database layer. The DAL (Data Access Layer) is a must to have on this type of
applications and certainly I think that LINQ cannot be used to write
queries that works directly with the database embedded on your classes.
Stored procedure and a separate DAL is always the best choice.
But... imagine if you have a separate DAL that works with the DB, exactly
like a best practice of data-driven applications. This DAL can return
you a set of data and in your code you can manipulate these data (search
operations, calculations etc.) via a LINQ code. Your class is totally
independent from the database layer but the operations on the retrieved data
could be more quick and powerful (and easy to write).
So, LINQ Yes or LINQ No?
Certainly I've a lot to understand about it, but I think that LINQ is not an
"embedded stored procedure" that have to work directly with a database...
Maintain the separate logic between data and application and LINQ will be a
great tool to work with. And so? My answer is LINQ Yes! 