By my estimations (and minor research), most common business applications being written today are in Java, VB.Net and C#.  The languages are similar in many respects, not the least of which is that they are all object-oriented languages. I am aware that many if not most business applications written in these languages ignore 40+ years of object theory and proven layered architecture benefits on their way to a lovely big ball of mud.

However, there are legions of developers who do try to tap into the benefits of using an object-oriented design and a layered architecture to produce robust applications that are easy to build, understand, change, and maintain. When they do so they will make a decision as to whether an object representing a business concept will have methods for maintenance-related code or whether it will have methods that handle business logic. Rarely do objects have both as the two needs often lend themselves to different designs.

In the past year or so I have come to the surprising realization that most developers seem to make the methods of their objects maintenance related. The objects tend to be mutable bags of data that act only as a conduit to database tables for moving data in and out, business seems like an afterthought.  Frameworks like nHibernate and CSLA promote this kind of design in much the way Microsoft does which is ironic since users of nHibernate and other O/R mapping tools tend to be anti-Microsoft developers.

Gone or least fading is the idea of objects that represent business entities actually having only methods that relate to the business of the object, in other words, they are true business objects.  However, I’m not sure how an object-oriented developer whose emphasis is modeling a business in code rationalizes any other kind of design.