views:

189

answers:

8

Hey,

I have just been looking into Linq with ASP.Net. It is very neat indeed. I was just wondering - how do all the classes get populated? I mean in ASP.Net, suppose you have a Linq file called Catalogue, and you then use a For loop to loop through Catalogue.Products and print each Product name. How do the details get stored? Does it just go through the Products table on page load and create another instance of class Product for each row, effectively copying an entire table into an array of class Product?

If so, I think I have created a system very much like this, in the sense that there is a SiteContent module with an instance of each Manager class - for example there is UserManager, ProductManager, SettingManager and alike. UserManager contains an instance of the User class for each row in the Users table. They also contain methods such as Create, Update and Remove. These Managers and their "Items" are created on every page load. This just makes it nice and easy to access users, products, settings etc in every page as far as I, the developer, am concerned. Any any subsequent pages I need to create, I just need to reference SiteContent.UserManager to access a list of users, rather than executing a query from within that page (ie this method separates out data access from the workings of the page, in the same way as using code behind separates out the workings of the page from how the page is layed out).

However the problem is that this technique seems rather slow. I mean it is effectively creating a database on every page load, taking data from another database. I have taken measures such as preventing, for example, the ProductManager from being created if it is not referenced on page load. Therefore it does not load data into storage when it is not needed.

My question is basically whether my technique does the exact same thing as Linq, in the sense of duplicating data from tables into properties of classes..

Thanks in advance for any advice or answers about this.

Regards,

Richard Clarke

A: 

In Linq, You create a data context which manages the data changes between the database and the object model.

There are tools ie designer, or sqlmetal that allow you to create a mapping between the database table fields and the object model.

In the case of a disconnected model such as asp.net you can use attach methods to maintain field updates etc.

I am currently reading a really good book on Linq called Linq in Action, which provides a good introduction to Linq. As far as comparing your model to what Linq does, you might want to do a bit of reading, as Linq performs quite a lot of management between managing the objects at the code level and translating this code to the data layer.

With Linq to SQL there is a Expression layer that converts object code to sql using a data provider that is quite intense.

Linq exposes this expression layer to you using something called Expression Trees. You can then modify these nodes in the expression tree to modify the the code that then gets generated at the data layer.

Joe Pitz
+1  A: 

You're going to need to spend a little time familiarizing yourself with the LINQ syntax and understanding how to extract only the data you need. I recommend downloading LINQPad...detailed examples and gives you a nice sandbox to play in and get your feet wet. There'll be time to get more involved once you get the basics down...

Neil T.
+1 for the link to LinqPad... looks like a nice tool.
Andy West
+8  A: 

Linq to SQL does not maintain copies of all the data in the database. It takes the expressions you feed it through the IQueryable interfaces, reads the expression trees, and converts them to actual SQL statements using WHERE and other SQL constructs.

In other words, when you write this:

var product = context.Products.Where(p => p.ID == 50).SingleOrDefault();

It executes this against the database:

SELECT ID, Name, Foo, Bar, Baz, Blah, ...
FROM Products
WHERE ProductID = 50

It does not just do a SELECT * FROM Products and then search for the specific product from within the results.

Your application will be slow indeed if you try to "download" the entire database on every page load. That is definitely not what Linq to SQL, Linq to Entities, or any other ORM framework does.

Aaronaught
+1 nice explanation!
marc_s
Just to add: and that is technology that I have used nearly 20 years ago. 10 years ago on C#. Nothing new, lots of literature around about it.
TomTom
Thanks for the reply. I think maybe this answer explains it to me in a way that I can easily understand (not saying I cant understand the other answers..). I have only dipped into Linq a bit, since my entire project (and dissertation) is due in in less than 2 months, and ive not done much dissertation yet :(. This is something I could quite easily comment on as something I wouldve changed if I had the time to.Thanks to all for the answers - much appreciated.Regards,Richard
ClarkeyBoy
A: 

The LINQ To SQL Provider is in collusion with the C# compiler, the IQueryable interface behaves a little differently upon compilation as opposed to a standard in memory collection (IEnumerable). Expression trees are built, this post is very helpful in understanding on whats going on underneath the covers. The LINQ to SQL Provider accepts Expressions, not Funcs and actions. See the post for details.

RandomNoob
Collusion? Not unless you include every .net compiled language and also every linq provider (such as LinqToEntities). Then it's more like a party than collusion.
David B
Didn't realize this was a forum on semantics.
RandomNoob
+2  A: 

Linq-to-SQL definitely does not "create a database on every page load"..... you need to get your head around how Linq-to-SQL work, and what it does.

My recommendation: check out the multi-part series of blog post by "The Gu" - Scott Guthrie - and soak up all those perls of wisdom in those posts.

A lot of the magic is hidden behind the visual designer, which basically creates a "snapshot" of the table structures - but only of the structures! And it knows how to convert your "gimme those records" queries into straight T-SQL queries against the SQL Server backend. And it converts those relational bits and pieces into nice .NET objects.

Sufficiently advanced technology is always almost indistinguishable from magic - but Linq and Linq-to-SQL really aren't black magic - just very clever pieces of code by some bright guys!

marc_s
Pop open the `ObjectReaderCompiler` in Reflector and try telling me that all those `Emit` calls are anything but black magic. ;)
Aaronaught
@Aaronaught: ok, *most* of LINQ and Linq-to-SQL is really no black magic - some parts might be :-)
marc_s
A: 

LINQ to SQL is like many Object Relationship Mapping solutions and creates objects and collections which abstract the tables into object-oriented entities. Your approach to create manager classes for different entities is a little overblown and will become unwieldy easily. You may want to look at using the Repository Pattern and Domain Driven Design which effectively means you will group together entities that are associated into a couple of high level classes.

Nissan Fan
+2  A: 

Magic ;-)

No, but it is pretty magical. How LINQ works is pretty complex, but I've found that I virtually always get better or equal performance with LINQ and the code is always cleaner.

If you want to play with LINQ, download LINQPad and go through the samples. Then buy Joe Albahari's (the author's) book, C# 4.0 In a Nutshell for all the gory details!

Pat
+1: for LinqPad!
Brett Widmeier
A: 

Linq is a collection of monads. How monads work is described by category theory. So if you really, really want to know, look up monads.

Richard Hein