Splitting CSLA Business Objects into client-side and server-side methods

[shantisoftware]

From what I understand, the entire point of CSLA business objects is that they are available to both both client-side and server-side operations. Some of our methods can be called from EITHER the client directly, OR as a nested call from some other server-side operations.
eg. the client can call ReceivePurchaseItem, or they can call ReceivePurchaseOrder, which in turn calls ReceivePurchaseItem for each item.

In the first case ReceivePurchaseItem must go across the data-portal first. In the second case we are already on the server.

How do I mark my BOL methods to ensure the developers don't call server-side code directly from the client-side without going over the data portal.

Our current approach is to create an async wrapper for each method that also invokes DataPortal.ExecuteAsync, which then calls the core server-side method. The method name is the original suffixed with 'Async'.
Our internal policy is then:
all UI calls to the BOL must use the Async methods,
all server-side code must NOT use the Async methods.

Does this make sense or are we missing something entirely with our architecture?

[rockfordlhotka]

Part of the solution might be to apply the single responsibility pattern. Each business class (object) should have one responsibility, not more.

A responsibility might be "get valid information from the user", so you'd probably create a BusinessBase subclass with read-write properties that have various rules associated.

A responsibility might be "receive a purchase item" that does some database transaction relevant to that responsibility, so you'd probably create a CommandBase subclass that can execute the work.

Or perhaps the "receive a purchase item" work requires that the user enter the item ID or something? In which case it might be implemented as a BusinessBase subclass so it can get the id from the user, and then do the database stuff in the update data portal operation.

The overall design philosophy is this:

• properties are accessible on client or server
• data portal operation methods only execute on the logical server
• rules operate on client or server unless they invoke a server operation using a command object, in which case technically the rule is still running in its original context, and it is using an "agent" (the command object) to go run something on the server

Once your code is running in a data portal operation method, you can access properties, which may trigger rules - all of which will continue to run on the server.

Generally speaking, if you have some set of behaviors that must run on the server you'll wrap that set of behaviors into a unit of work object, often derived from CommandBase. That way, any time this unit of work is invoked, it'll be running on the server. If invoked from the client it'll go to the server first, or if already on the server, it'll run where it is.

[rockfordlhotka]

In short, I think you are overcomplicating things, and should work with the CSLA philosophy rather than trying to add another abstraction on top.

[shantisoftware]

Thanks very much for taking the time to respond Rocky.

Yes we have wrapped up these core shared functions into individual unit of work objects, derived from command base, as you suggested.

• Part of my question was 'if I'm already on the server, and I call DataPortal.Execute on the command object, how much wasted resources will go into running it via the data portal if it is already on the server'. I believe in version 4.5 you changed the local data proxy to always spin off a new thread so that behavior was the same, irrespective of execution location?

To ensure there isn't wastage, AND ensure we never run server-side functions without going via the portal, we have decided that each Unit of work object has

• a private Core method that does the actual work.
• a public async method that calls the Core method via DataPortal.ExecAsync (since we only use async client-side)
• a public sync method that checks the LogicalExecutionLocation, and determines if it can call the core method directly, or via the data portal.

So I think this covers our use case where we have these shared functions (unit of work objects), and shields the developers from having to think about where the shared function might be called from in some future development.

• Am I still hanging on to old patterns with these shared functions, or is this an acceptable approach?