Separate between data and functionality

Separate between data and functionality

Old forum URL: forums.lhotka.net/forums/t/4012.aspx


shaih posted on Monday, December 10, 2007

Any suggestions/comments about separating the data from the business logic?

 

The idea is to have classes that will hold only data and put the functionality on the data in other class. For example:

Class Project – will hold project data properties and the list of assigned resources

Class ProjectBizLogic – will hold all functionality that we can do on the data (load projects from DB, add resource, delete project)

 

This way we have objects with thin memory print (cached data) and stateless BizLogic objects.

 

Does the framework support the above configuration?

 

Thanks

Shai  

RockfordLhotka replied on Monday, December 10, 2007

This is a totally valid architecture. But it is almost diametrically opposite from the philosophy of CSLA.

This "passive data" architecture works really well for block mode user experiences (mainframe terminals, web browsers, etc) but works very poorly for interactive user experiences (Windows, WPF, Silverlight). The reason for this, is that a UI will typically set the properties of the passive data object, and once all the properties are set then the data object is pumped through the business object to do any business processing.

The "passive data" architecture works really well for batch processing as well. In fact, this is the model preferred (often required) by workflow engines and business rule engines - except you don't create objects for the business processing because that processing is in the workflow or rules engine.

CSLA supports the opposite idea. The idea that behavior and related data should be encapsulated within an object, so you can interact with the object and get natural and immediate results. This "active data" architecture works really well for interactive user experiences and is OK for block mode scenarios. And it is OK for batch processing.

In other words (and this is just my view on things), "passive data" is excellent in a couple scenarios but it terrible for the interactive scenario. "Active data" is excellent for interactive scenarios and is OK for the other two scenarios.

So give "passive" two A's and an F, and give "active" an A, B and C. The result is a C+ for "passive" and a B for "active". Add to this that "passive" really is terrible for interactive user experiences and you see why I work so hard to make CSLA support the "active" model.

Copyright (c) Marimer LLC