“The truth is rarely pure and never simple” ~ Oscar Wilde

Don’t you just hate those unoriginal movie reviews, book reviews, magazine articles, and newspaper columns that start with some famous quote and then distort their subject matter to make it fit that quote? Me too, but how could I resist? I have never claimed to be original in my writings about software development, so why start now?

The most interesting thing about this book is that it was available at my local library. I can’t even recall why I thought to look on the library’s website, but for no money down I was reading Expert C# Business Objects within a day of being asked to. You see, a colleague of mine at the office asked me to read it and share my thoughts. So I thought I would blog my review since my convention of late has been to share all thoughts on software design and development in this blog.

What’s in a name?

The title of the book implied to me that it would be about the discovering and designing of business objects, expert business objects. When initially learning about modeling business objects the simplest analysis involves seeking out the nouns of the business and the verbs associated with those nouns. This is a good start but the result is usually a basic and naïve model of the business. Expert business objects come from a deeper understanding of the business and analysis of object patterns. This is a very tough skill that I don’t claim to have mastered myself, but a book called Expert Business Objects could probably help you learn. Unless of course the title of that book should be CSLA .Net Reference Manual: A Framework for Business Objects. You see the book is not about creating expertly designed business objects, but rather understanding the CSLA.Net framework that Mr. Lhotka has created and using its provided classes as a base for your own business objects. I can’t blame the guy for this clever marketing trick. Who is going to buy a book called the CSLA .Net Reference Manual: A Framework for Business Objects? Expert Business Objects is much more enticing. However, now at least we know what we are reading; a book that describes his framework, its benefits, and instructions on how to implement it in your next business application.

Frankenstein-work

What is a framework in the realm of software design? In a general sense it is a support structure that facilitates the development of software projects assuming a defined set of constraints. The framework often consists of libraries of code and established structures to help do the most common of operations used by many applications that fit within the constraints given. So if you wanted to build an application strongly based on Microsoft technologies then it would be very beneficial to take advantage of the .NET framework. You’ll have to code within the constraints of the .NET framework but that’s fine as it is wide open. However if you wanted to build a non-Microsoft web application strongly based on the Model View Controller pattern then Ruby on Rails  might be the framework for you. And finally, if you wanted to build a scaleable .NET business application heavily focused on changing business data, or using a Table Driven Design, then Rockford Lhotka’s Component Based Scalable Logical Architecture (CSLA) might be perfect for you. This book then is also for you because it is like an 800 page manual for understanding and using his framework. Doctor Lhotkanstein has produced a framework that provides 8 specific features that then become intrinsic to each of your business objects by providing a powerful base class.

• Unlimited undo of changes to business object data
• Mechanism for managing business rule validation
• Managing changed data with in an object….(isDirty flag)
• Supporting strongly typed collections
• A simple and abstract model for a UI developer
• Full support of data binding
• Object persistence
• Table driven security 

Table Driven Design

When developing an application that has business data that is rapidly changing and thus the thrust of the business is managing this changing data, then this framework can be very useful. The hallmark of this kind of application is a user interface that is full of data entry fields for editing and adding data. Business application developers will often start with a design like this as an easy way to provide access to a database. Microsoft Access is obviously a perfect tool for this on a small scale. The CSLA and its base objects seem to promote this kind of design which often leads to what I call a table centric, or table driven design.

A Table Driven design results in database tables and matching business objects that represent the “nouns” of the business. This comes from starting with tables to hold data required for the application. Business objects that then match those tables are created with some methods related to that data. A user interface is fashioned to edit these objects and thus the tables behind them in order to fulfill requirements of the system. So imagine we have an (over simplified) Shipping Business. We have a business entity called Customer that has a phone number and a State (where they do business). So we then have a Customer table with a State Code field and a Phone Number field. We also then have a Customer business object with a State Code Property and a Phone Number property.

Here’s where the frameworks benefits come in…

We create a UI for editing customer data.

• Unlimited undo of changes to data
• A user can change numerous things on the Customer object via the UI and then just tell the Customer object to undo changes if the user hits the cancel button. The undoing of changes is facilitated by the framework. No extra coding needs to be done by the developers to accomplish this.
• Mechanism for managing business rule validation
• A user could enter “abcd” for the phone number and the business object can tell the coder (and thus the user) why this breaks a business rule. This is done with minimal coding by the developer as a business rules type of collection is provided by the framework to encapsulate this need.
• Managing changed data within an object….(isDirty flag)
• When the user is done with the form and they choose OK, the object knows if it is dirty and what fields changed and require updating. Again, minimal code is needed by the developers as most of this functionality is provided by the framework’s base business object class.
• Supporting strongly typed collections
• The framework provides a collection base that provides the other features mentioned here so collections work the same way. However, truly the strongly typed part is no different then normal as coders add a line to the ADD routine and any routine that pulls from the collection to cast objects correctly.
• A simple and abstract model for a UI developer
• Because of the previous three features and the type of design this framework promotes, developing a UI is simplified.
• Full support of data binding
• Data centric designs often require the straight viewing and editing of tables/objects thus making use of data binding a real time saver.
• Object persistence
• Object data needs to be persisted back to their corresponding tables and this part of the framework provides the infrastructure necessary to send objects off to storage automating some of the common coding always involved.
• Table driven security
• The framework provides a basic User name, password, and group management system for authenticating users, etc.

I need to clarify that nowhere in the book does the author promote a Table Driven design outright. Rather, I feel that most of the features the framework supports are valued when using a table driven design.

Frameworks? We don’t need no stinking frameworks!

I have to admit right off the bat that I am biased against off-the-shelf frameworks trying to provide a common environment for building a certain type of application within a base framework.  I will admit that on the upside we expect less code to be written and the framework code is probably mature. However, on the downside we still have to spend time evaluating and understanding it before using it. (It is much easier to be an expert at our own stuff then someone else’s.) Also, Frameworks may introduce platform and complier dependencies we are not interested in. And finally, frameworks create a design boundary that actually makes “thinking outside the box” nearly impossible. Furthermore, a framework that is not a good fit for your design methods can be just as bad as no structure as developers come up with their own ways to subvert the framework and create plenty of unique and unreadable code.

As far as the CSLA is concerned, it comes with an 800 page manual. Yikes, talk about understanding and evaluating a framework. When my next job wants me to develop business applications using Java….what am I to do? I don’t even understand how the CSLA did its magic, so can I still create the same quality apps without it?

Let’s imagine someone could convince me that I can get by without fully understanding the 800 page manual’s contents, and that they are sure I will keep my same job writing software on a client supported by the CSLA forever, and that I won’t want to do anything in regards to my business objects different than their inherited functionality. Even if we imagine this scenario, I cannot envision anyone convincing me to adopt a Table Driven Design on business applications that bear any significance, or to adopt a framework that will promote this kind of design from the more novice programmers in the group.

When I was invited to read this book and I hinted at my initial reservations, I was asked why I would bother reinventing the wheel in regards to my own framework every time I wrote a business application. In other words, why would I write my own framework for writing business applications every time I had to write a new one, when this one can be provided for me and I could focus exclusively on the business aspect of the project? I found this a bit ironic simply because all I tend to think about is the business. So much so that it ends up shaping “my framework” and thus “my framework” is different depending on each business and the operations within that business.  Just as my business objects grow and change with a deeper understanding of the business, so does my framework.

I prefer that this “framework” I am building is not an effort to build a hugely rich structure, but rather to find a minimal structure that solves only the problems that have come forward as I learn more about the business…less is more.  Furthermore, the concept of “my framework” is not really accurate. I don’t write a framework per say, as opposed to just having a few shared modules that provide some common functionality. And I tend to follow some general design patterns known to help implement some activities separate from the business - like database management and object-relational mapping.  These tend to vary quite a bit based on the business that is driving them, the specific constraints of the system and the constraints and policy of the company I am working for.

The CSLA touts 8 features for building a business application. I have no use for them. OK, maybe that is too strong. Let’s say I have no use for them except in some of the most trivial places in my application. So basing all my business objects on a framework that is designed specifically for these 8 features is overkill to say the least. Let’s take a look at each one of them individually.

• Unlimited undo of changes to data
• I have no need for this. I do not have power users who essentially edit tables in a database to achieve functionality. Instead user interfaces are created as a means to make business processes go to work and rarely are there cases of direct table interaction via an object that matches a table. If there is, then I deal with it in limited scale and surely do not make all my other business objects follow the same pattern. So except for trivial parts of the application, I have no use for this. This is not to say that undo functionality is not required in a system that has a lot of data entry, and data changes. However, even in these cases, a user interface can handle this in other ways without polluting the business objects. For example a simple cancel button on a form “undoes” what was changed on a form. I have yet to work on an application that is driven by a business of creating and maintaining data. Though I have seen many that were designed as if they are.
• Mechanism for managing business rule validation
• This I have done before as needed. But often it is accomplished by a simple string collection, or single string. No objects are created or added to the repertoire of tools and developers are free to manage this as each case requires. In cases where I have built a simple object it was made special by its needs like in the case of a web or phone application. It was also specific to the application in how it formatted itself, etc. Since this is not that complicated and is often specialized, I have no use for this feature.
• Managing changed data with in an object….(isDirty flag)
• I, like many, prefer that business objects do not change, they are always valid. The objects can assume this at all times while doing their business. It is never in question, it is never “managed”, it is much simpler to code and test knowing this. I have no use for this. When there is a rare need to have an object’s state change it is usually an implementation object used for a purpose other than “business” - like managing input from a form, collecting data imported from a file, tracking a process, etc. In other words, it is not a business object, and still the concept of “IsDitry” is not relevant.
• Supporting strongly typed collections
• This is a good thing. I do it by casting the objects as they “leave” a collection, and by requiring a certain type when being added to the collection. The CSLA .Net Reference Manual says you still have to write this same code.  I have use for this one, but it is not automated by the CSLA anyway.
• A simple and abstract model for a UI developer
• This is true that a table centric design lends itself to very simple UI code, as does an application centered on changing established business entities. A user knows to edit this business object and that business object for a given purpose. The UI coder won’t have to think about how to interface with a user to provide a meaningful refined experience for a user trying to accomplish tasks in the most efficient and clear way. However, I think they should, so I have no use for this. Not to say a UI developer should have a confusing interface to the business objects, but that they should not follow a design that allows for simple data binding and table editing as this does not provide for a polished experience for a user. Furthermore, it often results in a UI developer with little connection or understanding of the business.
• Full support of data binding
• See - Sign number 5 that you might be a code writing hack
• Object persistence
• This is obviously required for any application that requires persistence of data. How you do it will vary based on numerous factors that you should be conscious of and not hidden in an underlying framework. The CSLA framework includes all aspects of object persistence within the objects themselves further adding to the complexity of the objects instead of letting them deal with one thing….their business. The benefit here is that the business objects can keep their members private since no one else has to read them in order to store the data. Many developers are on both sides of the fence on this, I fall on the side of making another object manage persistence and simplify the business objects at the expense of members that are not private. The data portal concept as described in the book is a solid design pattern for someone who prefers objects managing their own persistence. My advice would still be to follow the data portal pattern and adapt it to your own needs if you think your business objects should manage the non-business task of storing data.
• Table driven security
• Oh if ever security was this simple. I might have use for this as a model or pattern to follow for simple design but I will count on it to change.

Concluding Thoughts….

There are applications that can benefit from this type of design and the CSLA framework, but in the realm of business applications I think they are few and far between. However, this is a very straightforward way to build applications, so it is easy for a developer to believe that this can be applied to every application they face.  (When you have a hammer, everything looks like a nail.) Often, I think the result is an application highly coupled to the implementation of storage, with quasi-business objects that have complexity above and beyond their true business complexity, no core system that can be cleanly modeled and understood by non-technical team members, and a user interface that is often no more than just a front-end to a database.  Again, I think the CSLA framework promotes this kind of design; it does not enforce it or stop you from building a more solid design.

I think Mr. Lohtka is a smart man who knows that many, if not too many, developers do build business applications using a simple edit and save design, and he is providing a useful tool for them, not for me.  I cannot recommend a book that encourages a Table Driven Design approach (whether on purpose or not) as a solution to significant business applications. Furthermore, code samples that show things like how the author handles dates that may or may not exist and statements like “Most of the time, applications don’t care about the difference between a null value and an empty value” makes me a little uncomfortable with the code that supports this framework and only further drives me to learn from his designs, yet implement them myself as needed.

I obviously have not seen every type of business application that can be built. However, I have developed quite a few business applications in the past 10+ years and I have not yet found myself yearning for n-level undo, management of “IsDirty” flags, and data binding. So when a book promotes a framework that simplifies these among other things I don’t currently do…..I am simply not interested.  When the person who asked me to read this book asked me why I was so intent on reinventing the wheel every time I developed a business application, I did not realize at the time he assumed I used a wheel.