Business process and process object - Best practices?

Business process and process object - Best practices?

Old forum URL:

ColourHaze posted on Thursday, May 30, 2013


I’m trying to grasp the concept of modelling a business process using CSLA.NET. As far as I understand the concept of business objects the golden rule is all about finding, centralizing and encapsulating behaviour.  

But what happens when the business object is part of a process, or in other words, what if the business object is the entity moving through the business process? In this case it seems unnatural to place the behaviour of the process inside the object, as the process describes the workflow for an object and not the other way around.

Point 5 of Rocky's post on deciding to use (or not use) CSLA.NET ( he wrote:

"An extension of a command object is a process object, that orchestrates a complex business process or workflow through the use of entity business objects."

The command object is quite obvious of course, but what about the process object? It doesn’t seem like a pattern is defined for this. At first I thought it matched the state pattern or chain of responsibility, but that doesn’t seem to be the case.

I also found a nice pattern called the sequential execution orchestrator pattern ( which might be useful. I still need to test this one however.

The use of course of WWF doesn’t seem like a real option. I have the feeling that is just a temporary thing, and that a more “raw” approach is much cleaner.

So I’m curious how you guys would approach this scenario? Are there best practices, patterns, or anything like that within the world of OO?

Thanks in advance for your response,

Best regards,


RockfordLhotka replied on Friday, May 31, 2013

The 'Using CSLA 4: Business Object Implementation' ebook discusses this topic at some length, covering key concepts such as a command object and a unit of work object.

CSLA has the CommandBase class that is designed to support scenarios where the object model must represent an action with little or no data in the object model itself.

It is also very common to use ReadOnlyBase to implement scenarios where numerous objects must be retrieved as a unit. Although you can implement this with a CommandBase too, it is more efficient to use a ReadOnlyBase for pure object retrieval scenarios.

But those concepts focus primarily on the business object model exposed to the presentation layer, and they work well for scenarios where the user (or in broader terms the caller) will be waiting for the results of the operation. If you need truly async batch operations on the server then you need more components in the picture.

Specifically, if you use a command object to launch an async batch process, that batch process must run in some server-side host process that won't get recycled. That rules out hosting in IIS. Remaining options include:

How you implement the batch process that runs inside your host process, and how you trigger that host process to actually start is largely up to you.

If you use an MSMQ listener Microsoft handles the triggering part for you, but you still need to write the code that processes the MSMQ message. If you create your own daemon (Windows service) you can trigger in many ways, including:

Again, once you've realized there's work to be done by reading something from a queue/table you still need to write the code that processes the message.

To process the message you have many options. You might:

I'm not a big proponent of WF, so personally I tend to gravitate toward the use of normal .NET code for these sorts of thing.

Either way though, your .NET code or your WF tasks (written in .NET too btw) can make use of your CSLA business classes if that makes sense.

Copyright (c) Marimer LLC