What to pass over the wire?

greengumby posted on Thursday, October 01, 2009

Hi Guys,

After some advice here on Silverlight and the WCF DataPortal.
We all talk about SRP and Modelling objects on behaviour instead of data etc
Im wondering if that changes because of the DataPortal and sending CSLA objects across the wire.

Ill try to explain. :)

Currently I have a use case where a Staff Member can fetch/edit all the details of a student including parents guardians address details etc.


Even though all this happens on one screen I can see that really this use case as being able to be divided.


So for example I have a user story that says I can fetch/edit the details of a Parent and I have a userstory that can fetch/edit the details of a Student.

2 BusinessBase's ParentBusinessBase and StudentBusinessBase.


My question lies at the Silverlight end. I don't want to make 15 calls to the WCF layer Fetching all these BusinessBase's just to provide data to the screen.
I want to make one call to retrieve the StudentBusinessBase data and Lazy Load the rest.


So I will essentially have to create a some sort of BusinessBase class that represents the View and have StudentBusinessBase and ParentBusinessBase as properties of the view.
Then taking this a step further lets say I have a AddParentToStudentCommand that handles the relationship. Is it now up to this View object to call Execute?


Am I using CSLA for what it is intended for?


Any advice is greatly appreciated
Jeremy

RockfordLhotka replied on Friday, October 02, 2009

There's a valuable concept called "unit of work" that can enter in here. There are other names for it as well, but this is the name I prefer.

The idea is that you have a form that requires numerous root business objects to work - this may be 1+ editable business objects and 1+ read-only objects like name/value lists.

You don't want to go across the wire for each object - understandably.

So create a "unit of work" object that goes to the server, gets all the required objects, and brings them back. This UOW object can be created by subclassing ReadOnlyBase or CommandBase. If you are only retrieving data I'd use ROB, and if you are also updating data I'd use CB.

Either way, your root objects don't change - you are simply creating another object to "ferry them over the network" in a single server call.

rsbaker0 replied on Saturday, October 03, 2009

RockfordLhotka:

... If you are only retrieving data I'd use ROB, and if you are also updating data I'd use CB.

Either way, your root objects don't change - you are simply creating another object to "ferry them over the network" in a single server call.

I think this is where I have perhaps gone awry of the intended model, but it seems to work.

I started out using CommandBase object for UOW type operations, and then discovered I could use a BusinessBase derived class instead to compose these "root" objects together and get other benefits (like my UOW can now expose bindable properties, have validation rules, etc.).

Since my UOW's are now also BusinessBase objects, they themselves can also be composed into higher level UOW's, etc.  One of the biggest benefits is that we can combine transactions server-side, which was virtually impossible in our legacy software.

JoeFallon1 replied on Saturday, October 03, 2009

This is pretty much the model I have been "preaching" for the last few years. Call it Unit Of Work (UOW) or Use Case Controller (UCC) it is the same idea. Use a Regular Business Base BO to be the parent object for the use case and have it gather up all the other objects when it is fetched. It can also co-ordinate the Update/Insert/Delete portion of the use case.

Joe