Stateful Business Objects

Hi everyone,

Most people seem to agree on how to divide the tiers in an n-tier system: 1-UI, 2-Business Objects, 3-Data Objects, 4-Database System. However, there seems to be two ways to deploy the business objects tier.

In Microsoft's web site and in books published by Microsoft Press, the business objects and data objects are deployed on an application server (usually with MTS). To minimize network traffic and server load, both tiers are designed to be as stateless as possible.

Recently, I've read Rockford Lhotka's Visual Basic 6 Business Objects. For the business objects tier, he recommends a "pure" object oriented design where objects have state, and practically everything is an object. For example, an invoice is represented by an invoice object. It will containt a collection of child objects representing line items. Fields are accessed via properties of objects.

To prevent the increase in network traffic and server load, he recommends putting the business objects on the client workstation. The data objects continue to be stateless and stay on the application server.

One advantage of this design is it allows a richer and more sensitive UI while maintaining a clean separation between presentation and business rules. For example, let's say you have a business rule that restricts a product code to 10 characters, and you want the error flagged the moment a user enters the 11th character. Try implementing that with stateless business objects residing on the application server. You can use the MaxLength property of the TextBox, but this would put the business rule on the UI.

I'm curious how many of you follow this approach. If you do, how do you solve the problem of upgrading business objects on several client workstations? If you follow the stateless business objects approach, how do you implement business rules like my example above? Are there any designs where you get the best of both worlds? Thanks.

Jason

Quote:

---

One advantage of this design is it allows a richer and more sensitive UI while maintaining a clean separation between presentation and business rules.

---

You said the above with regard to an object-oriented approach to your business objects. How is this achieved? Would you bind controls on your form directly to properties of you business objects?

Quote:

---

Originally posted by simonm


You said the above with regard to an object-oriented approach to your business objects. How is this achieved? Would you bind controls on your form directly to properties of you business objects?

---

This is one way to do it:

Let's say we have a Product object with a ProductCode property. The Property Let procedure will contain all business rules (e.g. max length is 10 characters) for this field. An error is raised when any business rules are broken. Otherwise, the new value is saved in a private class variable.

We can then set this property from a text box's change event. The moment a business rule is violated (e.g we enter the 11th character) an error is raised. In our error handling routine, we change text box's value back to the ProductCode property (which contains the most recent valid value). We can also inform the user of the error through a message box if we want too.

The user doesn't need to wait until the save button is clicked to know about the error. All business rules for a particular field is localized in that field's Property Let procedure. All record level business rules can be localized in a Save method. Making the UI this responsive and at the same time cleanly separating the business rules from the presentation is difficult to do with stateless business objects located on the application server.

By the way, I'm not advocating the above design. I want to start a discussion on the pros and cons of this design as compared to a stateless design.

Jason

while i agree with the concept of moving towards a more fully object oriented data and handling abstract, I would have to believe that anyone who uses any one idea to approach every problem would fail to use the best approach in each individual task. All of the ideas that have been used for programming are important to consider when creating an individual project. The use of procedural programming and objects together would tend to allow for the flexibility needed when approaching any project. The requirements of the particular task are the best consideration for each project..While the idea of keeping business rules on the client may be apropriate for a small network the requirements that follow any business and the changes inherent in that business would make it important to keep a strong view on the need to change and upgrade those very business rules...and when you consider that the world is moving towards an internet distributed business...it would be wise to remember the GOLDEN RULE....Highly Cohesive , Yet Loosely Coupled.....
in other words...build your project with the idea that each part handles only one single task and can easily be moved or modified...yet it is the sum of those parts that produces a strong dynamic project......

my point of view..