Lazy loading revisited

Nettiers is a great tool but there is one thing that I don't understand there are such little posts here on the forum about the lazy loading subject.

For clarity, with lazy loading (I found the term here on the forum), I mean filling op the parent entity sources of a certain entity, example : you can deepload an Order entity to get a collection of its OrderDetail and the lazy loading process fills up the ProductIDSource (or whatever) of each orderline.

The only solution I know of to solve this problem is to loop to the orderdetailcollection  and fill up the source (parent) entities manually, and I agree ; that works (there is a problem though if you want to use it in a grid, but that's another issue).

The main problem with this solution is that for an order with 100 detaillines, you have 101 database accesses where it can be done in only 1 (with joining the concerned tables). There are some variations to this solution (eg getting the products from some cached collection) but they all have some drawbacks and never come close to the 1 query (with joins) solution.

My greatest frustration is that I think this is the basics of the basics and that I can't find it in nettiers which is for the rest is such a great tool !

Have you tried to use views to display the results in the grids?

jmartinez,

I know there are several workarounds for this problem, like the one you suggest.

My frustration is that no one seems to bother to use a workaround for a problem for which the most evident solution is using one query that joins the needed tables.

Let me give this example : the 'good practice' learns us to use stored procedures because they are faster and put less load on the db server (I did some testing ; the difference is not that spectacular) and I believe it's a good idea to do so. On the other hand we don't bother to go to the server a factor 10, 100 or even more times to solve the parentsource problem.

Pascal.

PS : I must admit that solving this problem might not be that easy in nettiers ...

I agree with you, as I also had problems to use "Databinding" of Grids and other Windows Controls (bindingNavigators, ...) with collections of objects (but that was a while ago with NetTiers 2 beta, I didn't tried since last releases of NetTiers)...

Every time it comes to speak about databinding objects with childs or parent relationships (just like the example you gave : order, orderDetail, products ...), I got answers telling me to use views and customized SP... I'm confused about that because it's not the meaning, I don't want to have to create many views/SP just to get NetTiers working fine in so common cases. I would expect to be able to bind my DataGrid to an orderCollection (or even using a binding navigator and custom detailed view control) and be able to display columns from orderDetail in the same grid without having to create views, SP or any other stuff, resulting in generating duplicated entities (ok, not exactly the same but, not different in business term).

I know this is not a NetTiers problem but a common DataBinding issue in .Net, but aren't there any solution ?
 

If any NetTiers team member has a specific advice or comment (what are the problems, what can be done 'til now, ...) to provide us about this issue, it would be nice and maybe we could understand how to go the step further using NetTiers...

Thanks for paying attention, I hope we'll get some feedback soon.

Mike. 

Miketrix,

I'm glad at least one member recognizes the problem, I'm not alone anymore

You are right, there is a databinding issue, but I believe that is not a nettiers issue but a .net or windows forms (don't know exactly). The solution I found for the binding problem is to create a property on the entity level that returns the wanted property in the parentIDSource.

The problem that remains is query-with-join issue ...

Pascal.

Before NetTiers, I used to use the ADO SHAPE command to get round this problem a few years ago. (For those that never used it, it basically allowed one recordset to be nested within another.) However I only ever worked for one company that allowed it to be used on a Live system.

My other approach was to have a standard prefix for each table, and every column in a stored procedure would use this prefix as an alias. I could then pass the recordset to each object and it could pull its own properties from the columns. All I had to do was manage the hierarchy.

Using NetTiers I would tend to write my own Builder methods to create the hierarchy, and stored procedures that return all the objects I need for each level at one go. However the envionment I work in at the moment means that investigating and fixing problems is more important than raw processing speed. I am not too worried about a few hundred database hits if the alternative is code that takes time to understand. I appreciate that other companies will have different requirements.