Introduction
Even though on a low level, LINQ may itself use subsets of ADO - this article focuses more on the programming aspect as a comparison between the two. I am also aware of the slight difference in "run-time" speed, in terms of data access times. However, again - we focus on differences during the development or "design-time" aspect thereof.
About ADO.Net
ADO.Net is an acronym for Advanced Data Objects. It is a subset of the .Net framework. The first versions which were "non .Net", were separate libraries for accessing data. However, as the of .Net Framework it has been incorporated as part thereof.
Accessing SQL based databases using ADO.Net is fast and efficient. However, data is often returned as different types or custom types, and have to be cast or formatted into usable or .Net or native types.
However, when working with web services, like WCF Services and Silverlight, it's a breeze to query data, compile the objects and send them across the service.
I will not go into a too detailed discussion regarding ADO.Net as it's been used for a long time and that is how most of the .Net developers access data.
About LINQ
LINQ is an acronym for Language INtegrated Query. For the purpose of this article, which focuses on C#, .Net and MS-SQL based data mainly, you may understand LINQ as the following: C# Syntax like SQL.
You must understand that any possible collection of objects can be queries with LINQ, where SQL is mostly related to data and querying databases. For example, you may query the Windows file system (like your C drive) as if it were a database or a collection of data - however, we will not look at that during this article.
The reason why LINQ is (or can be) so popular with developers, and me at least, is that it allows you to stay in your native programming language (C# in this instance) and query data, or any other collection of objects for that matter. Another nice feature, is the comparable native types it uses to build and return these objects.
Another problem I have with LINQ, is that it basically creates "it's own" version of the objects returned. This is not really a problem - and actually, it's one of the best features. It does a lot of the work for you. Let me explain. If you go through the process of creating a new database, it's data structures, communication layers, business rules, data entry and exist points, and start working with larger projects where such data libraries are shared between teams, you can imagine how complicated the SQL, Stored Procedures, etc. can get. As well as where things (like business rules) are located, in the database, or in the libraries. (But that is another can of worms for another article)
But let's get back to that problem I started the previous paragraph with - the issue I have, if you query (lets say) the user table, it will build user objects based on the data structure. If you then want to send this across a WCF service for instance, it creates a very hairy and difficult scenario to overcome. You have to either work some black magic with inheritance or even darker magic with WCF data contracts and really get your hands dirty in the WCF frameworks. However, it's so cumbersome you may actually completely get side-tracked and forget you are actually working with data, fetching it and returning it - and not communication layers and protocols. Another way, is to recreate each class or object entity, and write interfaces, or perhaps try and only work with native types in the methods. Other ways may exist, but this entire situation is a bit of a sticky one - I'm working on better ways to handle them every year. I will publish an article on my best solution in the near future.
However, if your application is less widely scoped, lets say, you have a typical .Net Windows App (WPF or Win-Forms) over a fast company network, linked to a database server - you will regret not using LINQ. It's only problematic when you start combining WCF or web services and LINQ.
Summary:
Have Any Questions, Most welcome, just mail to dotnetcircle@gmail.com
No comments:
Post a Comment