After lunch yesterday I continued the session on OO with Rocky.  I really appreciated the practical aspects of his presentation.  It is obvious he has been striving for OO purity and landing in the real world.  That is a difficult thing to do, but so often necessary.

Fro example he said that Tiers are bad.  He was speaking of physical ties in the architecture.  The obvious problem with Tiers include the deployment issues and performance issues.  The trade offs include scalability, fault tolerance and security.  At Idaho Commerce and Labor those of us doing more Object centric development have realized how painful it is that we are running on a web farm.  If the user sessions were sticky or we we running on a single front end box then we could use caching and working with object graphs would be smother.  So, I definitely understand and agree with Rocky that Tiers are bad.  I have also come to believe that many solutions would be best run on a simplified physical architecture.  So often more energy and money is put into redundancy than it would cost to have a hot spare standing by with instructions for staff on how to switch it over.  Of course there is no perfect one size fits all solution.

Another thing that struck me was Rocky's belief that using serialization is bad practice for persistence.  To clarify he was not talking about an in memory working set, but for long term storage.  Serialization is necessary for passing objects around, but has significant challenges when it is used as a more permanent storage mechanism.  The biggest problem is versioning.  Say you store an object and then have a need to modify the class by adding or removing properties.  Then you try to deserialize your stored object for version 1 of the class using the schema of version 2 of that same class.  OOps!  There are ways to deal with the versioning issues, but Rocky's opinion is that its not worth it.

I was impressed with the CSLA Data Portal concepts as they are similar to many of the ideas I have been considering in the past.  Primarily I like the concept of a single port of entry for storing and retrieving objects. 

My conclusion is that I want to use the CSLA framework.  It has been well tested in the real world.  Well improved since the book was printed.  Actively used in the community.  Strives for purity, and lands in reality. 

Only 1 major complaint I have and I need more experience to decide where to land.  Love to have feedback from others on this.  In the CSLA framework the Data Access methods are contained within the Business Object Classes themselves.  The pattern I prefer places the Data Access in its own classes.  I like to have a Manager class or service class has responsibility for persistence.  I asked Rocky about it and he is happy with his solution of course.   The reason is private members.  The only way to persist and retrieve private members is if you have access to them which means you are either inside the class or you are using reflection.  Reflection is expensive and much more difficult.  As I think about the purpose of private fields I realize that they certainly can and do exist without a public property accessor.  Also, the encapsulation of of property into a private field allows for some behavior in the Get/Set blocks.  Often you would not want that behavior to happen if you are merely recreating an object from a data store.  If the Object itself represented data and not behavior then it be much less of an issue.  Of course understanding Rocky's presentation that objects should model behavior and not data helps me to clearly understand his framework decisions.

Take a look at the ASP.NET 2.0 Membership system.  It uses the static Membership class for persistence and creation of MembershipUser.  This doesn't fit Rocky's model because the business object of Membership user is not responsible for its own persistence.  I like it much better though because the behavior of persistence is modeled separately than the behaviors around the authentication object. 

Anyone care to share their thoughts on this?  Is it a case or purity meets reality?  Perhaps some Objects best fit the CSLA model and others a different model?