.NET vNext: How LINQ Makes working with business objects better?
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.
(originated from: http://blah.winsmarts.com/2006-9-NET_vNext__How_LINQ_Makes_working_with_business_objects_better.aspx )
No comments:
Post a Comment