We at work came across a situation where an editableList type is being bound to the UI. When we make a change, the entire list is sent across the wire and the framework creates instances of each object that is bound to the collection and calls Update on it based on the IsDirty flag.
This can be a performance bottle-neck. What we have done is the following. We read in the collection again when the user hits save and check whether the object is savable [if (IsSavable)] and based on this we then call update within the BO on the DAL. This being our first foray into the Csla world, we did not know of any other approach that was better.
Thanks
If you are using an EditableRootListBase (ERLB) derived class, then only the object being actively edited is sent across the data portal for saving.
BusinessListBase (BLB) derived classes are indeed sent over en masse, but the usual use case for these is a child collection with an enclosing parent object, so they would be sent over the portal with the parent any time the parent was saved anyway.
In your solution, you're trying to improve performance by hitting the database again versus transmitting data you have already read. It's not at all clear to me that this would generally be either faster or more scalable. I'd use the framework as is and then tune the parts where you have issues once you have identified actual versus "potential" performance issues.
My experience has been that save operations are very fast compared to previous technologies we have used, even for BLB objects containing several hundred items.
The idea you are describing is often referred to as a "datagram" - a message composed of only changed data. This is something the DataSet does for you, for example.
CSLA doesn't do this, because it prevents your server-side code from being able to interact with the full object graph like the client can. In other words, mobile objects and datagrams are two different client/server models with two different sets of good/bad points.
Mobile objects are good because you have location transparency. You can write code that runs on the client or server or both, and (to a very large degree) the same object model and context will exist on both sides of the wire. This is very powerful, but does mean some unchanged data moves across the wire at times.
Datagrams are good because they minimize the data on the wire. But your client and server code can't ever be the same, because the server never knows if it has full access to the same object model or context.
CSLA supports the datagram model, just not through the data portal. The primary purpose of the data portal is to support mobile objects.
However, if you run the data portal in local mode, then your DataPortal_XYZ methods will run on the client. The client can then use a pure data access technology or service-based technologies to communicate with the server using the datagram model. Examples include WCF, asmx or .NET Data Services. And the DataSet is powerful here, because it can help you create these datagrams. Or you can define your own DTOs and create your own datagram messages.
Rocky,
Thanks for your response. I think I see what you are saying. The issue is in the template that we are using to generate the code (downloaded it from CodePlex). When I use the EditableRootList.cst it generated a type that inherited from BusinessListBase rather than the EditableRootListBase like you recommended.
Thanks and I will give it a shot.
Copyright (c) Marimer LLC