Hi,
I am coding a VB.NET application for which the database and its Stored procs are already written, The way the Stored procs are written, I can't possibly use the root and child objects as defined in the CSLA , because of the fact that every object should contact the Database by itself. The reason behind this is the Stored procs are pretty simple and return data for an object or a collection of objects.
Any suggestions? or Any one encountered the same problem?
Thanks
Ash
William,
I can probably understand why are the Stored procs like that, because if we follow the root and child objects model as we have in CSLA, then I will have one root object and 7 child obects, 4 child collection objects and 3 grand child collection objects, so apparently loading all these objects won't be a good idea?? (right? wrong?) considering its a web app.
Now coming to the question why I can't create root/child objects? It was not quite intuitive to me either :) :) because then all the stored procs (for the objects as I explained above) will be called by the root object, right ?
thanks
Ash
Ash,
The simplest way to handle this is to only have root editable objects and simply ignore child objects altogether. Or put root collections inside of root objects. The down side is that you lose transaction support meaning that a bug/crash could leave your parent and child objects in inconsistent states. I would strongly recommend writing additional stored procedures (at least for the fetch/update procs).
JonM,
Thanks for your help, Do you suggest
1) rewriting some of the stored procs like we have example Stored procs in ProjectTracker?
2) or using Trasactions (COM+) in VB.NET code (as supported by CSLA)
Thanks
Ash
Hi Ash,
Another option could be to call more than 1 stored procedure in the data access section of your root object. If there is a stored procedure to retrieve the child data seperatly, you should be able to call one (existing) stored procedure to get the root object data and then call another to get the child data. e.g.
Protected Overloads Sub DataPortal_Fetch(ByVal criteria As Object) 'Reset command object
.CommandText = "getClientChildren"
.Parameters.Clear
'Add any other parameters required for the child call including parent identifier
Using dr As New SafeDataReader(.ExecuteReader)
'Pass datareader to child collection
mClientChildren = ClientChildren.GetClientChild(dr)
End Using
End With
End Using
Instead of using the .NextResult method to move to the next datareader result, grab the data as an independant datareader and pass that to the child collection - the collection will not know the difference.
Remember that the Data Access section allows you to do anything to retrieve the data required. The object won't know the difference, and neither will its children. You could pull each child in a separate call if you wanted to, but that would be very wasteful.
I think that you should be able to use your existing stored procedures to retrieve the data that you need, you just have to plan how you are going to transform the data from the database into the objects, and this is what the Data Access section is for (or that's what I use it for with existsing db's)
Just thought I'd suggest a different approach. The more options the merrier
Ash,
There is no reason why CSLA child collections and child objects cannot handle their own persistence without any modification to the CSLA base classes. The implementation in Rocky's book is just a sample and can be modified to meet your needs. I have done similar in past and it can work with no problems.
There is also no reason why this can't happen all in the same transaction, particularly with .Net 2.0 transaction support. Just make sure your are not opening needless connections to the same database. Prior to .Net 2.0 you would have to manually pass the transaction around to all the child objects.
You should be cognizant of the fact that you will take a performance hit for making more calls to the database. One call that passes a large amount of data will perform better than many calls that each produce a subset. However if your object hierarchies and transaction volume are reasonably sized you should be able to get away with it without the user noticing.
Thanks,
Kevin
Hi again Ash,
I'm glad that my suggestion was helpful.
I think a bit of qualification is required due to the amount of responses you have received.
I work with Windows Clients exclusivley, so if your application is web-based there may be some better suggestions or additions that are more in line with what you are trying to do.
It would be good if you could document the procedures that you are using for the root and child object, then we all could see what you are up against.
xal had a great idea - make sure you establish what data you need before grabbing everything from your db. There is no need to grab a root object and 500 child objects if the user is only going to pick one child object from the list of 500. Lazy loading is definately a consideration in this situation.
Remember to think of your user when building your apps - there the ones who have to use it. One thing I do my best to avoid is having the user wait ages for the data to be retrieved from the db (that pisses me right off, and I've seen heaps of professional in-house programs that load thousands of objects into a treeview - after about 30 seconds or more I get to see the treeview).
Please keep us up-to-date on your progress.
Regards
Tray
Copyright (c) Marimer LLC