CSLA seems good for a windows form environment, but problematic for a web environment. For instance, one has to load a root object that may have many child objects, and in a web environment it would be better to load and save smaller amounts of information instead of having to cache a large object graph.
What ways have others found to make CSLA work more effectively in a web environment?
Mark Sulkowski
Having a root object with editable children supports a smart rich UI like Winforms, WPF and maybe Silverlight nicely. WIth ASP.Net/Web you would probably create extra business objects to load up children in "root editable" mode and that can be more efficient in terms of performance.
Rocky discusses this in the ASP.Net MVC eBook as he shows the additonal business objects for the POSTracker demo he needed to suit the MVC model and technology. Essentially you might find yourself enhancing your Domain model to suit the user stories that typically you need in a stateless web environment.
I would likely look into lazy loading then. It depends on your screens typically what your graph looks like. If you only want to allow the user to edit smaller amounts of data, then your objects only have that data. If the "child" objects can be edited independently you can have a lightweight list of readonly chlid objects which allow the user to select an object to edit, then load only that one full child object.
I suspect though that you're falling into the premature optimization antipattern. You're worrying about trading maintainablity for performance before you're even sure you have a performance problem.
I used Csla just fine in a web environment.
Yeah I would agree. Obviously a large object graph 'could' lead to performance problems, but you'd want proof before you do too much to optimise (especially early on...you never know how things are going to change!).
The way I've dealt with substantial object graphs is to do exactly what Andy has suggested and to allow the root object to have a read-only list of its children (with the minimium amount of data you can get away with), and allow the full editable Child object to load when requested...along with a list of any children it may have.
Obviously it really does depend on the system, but If you have large object graphs, it's unlikely that many 'child' objects are required (for editing by the user) and so this solution seems to work pretty well in a web environment.
One other thing, make use of 'Unit of Work' objects to ensure you are only making a single trip to the server to get all the data you require (e.g., the Business Object(s) & any lists for dropdowns etc.)
Copyright (c) Marimer LLC