.NET vNext: How LINQ Makes working with business objects better?

Posted on 9/7/2006 @ 12:49 PM in #Vanilla .NET by | Feedback | 6773 views

I have frequently talked about business objects versus datasets.  One of the biggest downsides of business objects is that you need to write custom code, which may not perform very well, to do simple things with your data such as filtering, sorting and performing aggregates/joins etc.

Also, because how we deal with data is so inherently different in the database and in object oriented languages that over time, we have come up with n-tier design architectures. These n-tier architectures are aimed at alienating, and thus limiting the impact each end (hierarchical) causes on the other (relational). We continue to segregate, and yet we are then faced with a simple business problem of filtering data, or sorting data, or anything that deals with working any significant amount of data, where we are forced to get down on our knees and traverse through all the layers we made in the first place, to ask the database and do the filtering for us.

Well of course this back-end could be a web service, which then calls a database. Either way, you are faced with one of the following two bad choices.

a) Traverse all your layers and let the database perform this data-crunching job.

b) Live with the cost of hand-writing bad performing code in a language like C# to perform the data crunching operation such as aggregating and joining or searching filtering sorting etc..

LINQ makes this picture better. LINQ will allow you to write queries against any business object structure (Entity). Thus your threshold for going back to the database for such operations is now greatly raised.

Now ADO.NET vNext involves a concept called “Client Views”, which you can query using either LINQ or eSQL. While you could certainly use LINQ to work against these client views, my feeling is that much like ASP.NET controls, you will see an emergence of third party ORM frameworks – which you will be able to LINQ against just as easily.

Thus in this blog post, I will focus on hydrating a business object in “whatever” mechanism, and then querying over that data using LINQ.

So assuming that my underlying relational structure or logical schema was the northwind database, my business object structure could look like this –

As you can see, I have a collection called “Customers” which holds Customer objects, and each customer has a property called “Address”. Now through whatever mechanism, I can persist this object structure. I am going to use a simple method as shown below:

Customers workingData = HelperClass.HydrateBO() ;

Of course this is an over simplified picture. Any serious ORM, including ADO.NET vNext will need a whole hoopla of an object tracking service where further changes done to the data are somehow tracked, so persistence because possible. Modifying data will be the responsibility of the underlying framework’s specific implementation. ADO.NET vNext does come with similar facilities, however that does not matter for the scope of this discussion though.

Now with such a business object hydrated, using LINQ, you can easily perform a search. For instance, what are the customers in London?

var londonCustomers = from c in workingData
          where c.CustomerAddress.City == "London"
          select c.Name ;


Console
.WriteLine("-- Customers in London") ;
foreach
(string custName in londonCustomers)
{
    Console.WriteLine(custName) ;

}

What are the customers in London, and could you sort them by

var londonCustomers = from c in workingData
          where c.CustomerAddress.City == "London"
          orderby c.Name
          select c.Name ;

Console.WriteLine("-- Customers in London sorted by Name") ;

foreach
(string custName in londonCustomers)
{
    Console.WriteLine(custName) ;

}

And what are all my customers, and when you give me the results, could you group them in the cities they are in? Also when you show me the results, sort them in descending order by their name and return me a hierarchical structure instead of a flat Rows X Columns structure.

var londonCustomers = from c in workingData
                      group c.Name by c.CustomerAddress.City into cityGroups
                      orderby cityGroups.Key descending
                      select cityGroups;

Console
.WriteLine("-- Customers grouped by City") ;

foreach (var cityGroup in londonCustomers)
{
    Console.WriteLine("Customers in " + cityGroup.Key + ":") ;
    foreach (string customerName in cityGroup)
    {
        Console.WriteLine("   " + customerName) ;
    }

}

Note that, in writing each one of these queries, I as the C# programmer do not have to first write a whole bunch of custom code specific to the business problem I am trying to solve. In other words, I am able to express myself and my intent with least typing. I like that.

Not only that, I do not have to make a roundtrip to the database, for such data crunching operations. If I had to do this without a database in C# 2.0, I would have no choice but to come up with some kind of inelegant object hierarchy matching algorithm, with plenty of string matches, a horrible memory usage, and a number of other disadvantages. That is usually the “worse” choice, and thus most people would choose to go over their 3 layers of code, and go to the database – the lesser of two evils.

Finally, it is also reasonable to expect that as we get closer to the release of all this stuff, the back-end engine that makes working with data possible in such an elegant manner will introduce a number of optimizations similar to a database engine. This will improve over the years and your application will continue to perform better and better with subsequent optimizations and improvements done in the database, uhh I mean, LINQ engine.

This, makes your business objects more palatable.

Sound off but keep it civil:

Older comments..


On 9/26/2006 1:14:49 PM Arne Claassen said ..
LINQ has me torn. As a programmer this looks fantastic, but as a former DBA, i worry what the LINQ code will do to talk to my DB? I usually use sprocs to insulate my DB design somewhat so that I can make schema changes without code breaking. So will LINQ require a fixed schema? I keep seeing articles of what LINQ looks like to the programmer, but what does it look like to the DB? Any resources?


On 1/13/2008 1:21:37 AM dhina said ..
Hi Arne,


you are right from the dba perspective. when we use the sprocs for our queries, it used to stay in a single repository for us to change those in the future. But with the introduction of linq, i guess,, all the queries will be embedded in the development environment itself. did you by any chance find doc with speak about this?


On 2/12/2008 8:52:25 AM Matt said ..
Interesting post Dhina, thanks for taking the time.

In a similar vein to Arne's comments, Stored procedures have been used historically to provide an interface into the database offering a) a way of enforcing interaction takes place through a layer of abstraction and the inherent security offered, b) encapsulation and c) optimisation and pre-compilation.

Do you see this being undermined by the advent of LINQ?