These base class servers (VPIDbp20.dll and VPIUis20.dll) and their associated templates encapsulate a number of design characteristics and behavior that should be part of any effective distributed application design. These include the following:

UI-Centric List Business Objects

UI-Centric List business objects provide behaviors which are typically used by the user interface, but which don’t interact directly with data sources. There are a number of behaviors common to all UI-Centric List business objects of dbObjects. These behaviors provide basic functionality to control how the object’s data is retrieved, constructed, formatted, and displayed.

The following is a comprehensive list of the methods and properties common to a List type UI-Centric object as defined by the dbObjects base class server (VPIUis20.dll):

Common Methods

Parent Child Relationships

There are a number of relationships that can occur between objects in an object-oriented setting. One of the most common is the "has-a" relationship. In this relationship, one object has a child object – implying a form of ownership or what we call in programming terms, containment.

For example, an Invoice object will have child LineItem objects. These LineItem objects can’t stand alone - and neither can the Invoice. The important concept to understand here is that the child objects are required by, and are really part of, the parent object. It does not make any sense that either can exist without the other.

Virtually every business application has some type of parent-child relationship between its objects. In most cases it goes even further because a child object can also act as a parent object and have child objects of its own (Grandchild objects). Because of this, the base classes and templates that come with dbObjects are designed to handle the issues associated with parent-child relationships.

Design for Edit objects

These parent-child relationships become very important when dealing with what we might call Edit objects (as opposed to List or Report objects). An Edit object provides behaviors associated with the edit or data maintenance process. When a user interacts with an object, the object data will be changed. One of the features that should be provided by proper Distributed Application design is to allow the objects to reset their data to an original point before any changes are made or committed – a form of undo. Child objects not only need to be able to undo changes if they are told to do so, but they may need to reset their state if their parent object is told to reset.

Additionally, since parent and child objects should not exist without each other, we can’t store a child objects data into the database without its parent object’s data being stored (and visa versa). This impacts how the objects are designed, as we want to ensure that anytime a parent object is stored or retrieved that its child objects are also stored or retrieved as appropriate. This is inherent within the base server classes of dbObjects.

UI-Centric Edit Business Objects

UI-Centric Edit business objects provide behaviors which are typically used by the user interface, but which don’t interact directly with data sources. There will be a number of properties and methods that will be specific to any given object such as the CustomerID, Name, Address, Phone, and others that might be associated with a Customer object, as an example. At the same time there are a number of behaviors common to all UI-Centric Edit business objects created that follow the Distributed Application model contained in dbObjects. These behaviors provide basic functionality to control how the object’s data is edited, with support for the concept of ‘undo’ to restore the original objects data if required. Other common behaviors are also supported, including tracking whether the object data is new, modified, or deleted, and more.

The following is a comprehensive list of the methods, properties, and events common to an Edit type UI-Centric object as defined by the dbObjects base class server (VPIUis20.dll):

Common Methods

Data-Centric Edit Business Objects

Data-Centric Edit business objects exist primarily to implement behaviors that require direct access to data sources. Going back to the concept of the Customer business object, We’ve already identified common behaviors and implemented rules for the UI-Centric portion, now we can review the common behaviors for the Data-Centric portion of that same conceptual object.

The Data-Centric objects have very few specific requirements in terms of properties or methods. However, the requirements that do exist are very important to ensure performance and scalability. Most Data-Centric business objects exist to provide create, read, update, and delete services for their UI-Centric counterparts.

To this end, three general methods are implemented within the base server objects of dbObjects (VPIDbp20.dll):

Common Methods

Methods in Data-Centric objects will be handled by COM/DCOM or Web Services. The UI-Centric object creates the reference, then makes a method call, and finally drops the reference, allowing DCOM or a Web Service to release the server-side object. When you make method calls using DCOM or Web Services, all parameters on your method need to be packaged up to be sent efficiently over the network. This process is called marshaling. One of the things that DCOM or Web Service SOAP (Simple Object Access Protocol) looks at when it marshals a method’s parameters is whether the parameter is being passed by reference or whether it is being passed by value. A parameter passed by reference is not only sent to the server, but it is also sent back to the client. This is because a parameter that is passed by reference can be changed within the called method and the calling code will expect to see any and all changes. A parameter passed by value is merely sent to the server. A one way trip. A parameter passed to a method by value can also be changed within the method, but the calling code expects that those changes will not effect its own version of the variable. Taking this into account you can minimize the amount of data going back and forth across the network by passing parameters by value whenever possible. Again, these design considerations are built into the Data-Centric base classes and templates of dbObjects.

UI design characteristics

The Distributed Application model we have been outlining allows you to create user interfaces that are quite robust – assuming your UI development tools or environments allows a high level of interaction with the user. Visual Basic form-based programs and DHTML script-based interfaces can be very interactive and responsive, while a basic HTML interface based on Active Server Pages (ASP) can’t be nearly so interactive. This does not prevent you from designing the business objects to allow you to create both types of UI with ease. The Distributed Application model as embodied within dbObjects provides for a specific set of capabilities to UI developers for their use. Individual developers may or may not choose to use these capabilities, or specific UI development environments or tools may preclude their use, but they will be there if needed.

OK, Cancel, and Apply buttons

One fundamental design is to make it easy for a UI developer to implement within the UI an OK, Cancel, and Apply command button on their forms or pages. Not all interfaces may provide all these buttons, but the basic behaviors of editing data and then being able to cancel or accept those changes are fundamental to almost all edit or maintenance type applications.

dbObjects also includes templates for Visual Basic forms that supply these general characteristics. Our UI-Centric business objects provide support for the behaviors associated with these buttons through the BeginTrans, CommitTrans, and RollbackTrans methods.

Before any editing of the object’s data is allowed, the UI developer must call the BeginTrans method – thus allowing the object to know that it is about to be changed so it can store is current state. If the user later clicks the Cancel button or otherwise indicates through the UI that they want to undo their changes, the UI can simply call the RollbackTrans method on the UI-Centric object - causing the object to reset its state to where it was when the BeginTrans method was called.

If the user clicks the OK or Apply button, or otherwise indicates through the UI that they want to commit their changes, the UI can simply call the CommitTrans method on the UI-Centric object. This tells the object that it can commit any changes - requiring that the BeginTrans method be called before any further editing is allowed.

Essentially, this type of behavior means that the UI developers can count on a single level of undo to be provided by all business objects. Regardless of the type of UI employed, changes to the object can always be undone by calling RollbackTrans.

At the same time, you have not precluded more batch-oriented operations such as you might find within a browser-based interface. Code in the web server can instantiate the UI-Centric business object, call the Load method and use its data to create a display page for the user and then discard the object – all without calling the BeginTrans method. If the user changes values in the browser and posts those changes back to the web server, code in the web server can again instantiate the object, call the BeginTrans method and update the values within the object itself. Then it can immediately all the CommitTrans method on the object and commit the changes, and finally release the reference to the object.

By supporting the concept of OK, Cancel, and Apply buttons dbObjects enables a very rich UI, but does not stop a UI developer from creating more basic types of interfaces if desired or needed.

Checking Business Rules

Much of the reason for basing your application on a set of business objects is to centralize the business logic and business validation code within the objects. This helps you avoid writing the same business code over and over again each time you need to use it. Instead you only need to write various user interfaces or other client code to use your business objects - thus reusing your business logic over and over.

One implication of this approach is that any UI code must rely on the business object to handle validation of data entry and enforcement of business rules. There are two ways that the business object can indicate that business rules are broken: either by raising the Valid event when the object becomes invalid, or by raising a trappable error. It then becomes the responsibility of the UI developer to respond when the business object either raises an error or the Valid event is fired.

n-Level Object state rollback

One of the first things that many people run into when implementing applications based on the Distributed Application model is the complexity involved in implementing n-level rollback for the UI-Centric business objects.

n-level rollback is the concept that the user can cancel changes they may have made to an object and have the object reset its data to the last saved state. The complexity comes when you marry this concept with n-levels of parent-child relationships and any rollback at a parent level should result in the rollback of all child objects along with any depended grandchild objects of the child objects. There are ways to implement methods that can cascade transaction processing between objects that have these types of relationships.

n-level object state rollback is an important design and implementation issue. The base UI-Centric objects and class templates from VantagePoint Software do address these issues and provide an implementation of n-level rollback that can be utilized in the development of business components. It is based on the concept of state stacking.

Serializing object state

In a distributed environment it is very important that we are able to transfer our objects data across the network very efficiently. When we have stacked child and grandchild objects this can become quite a challenge because we may have so many of them. The solution is to serialize each object’s state into a byte stream as a string. Once transferred, this string can be deserialized - or converted from the byte stream back into the detail state data for the object.

We serialize object state when we need to pass and eventually store object state between one object and its child objects if that "parent" object contains other objects. We also need to serialize object state when passing that state between the UI-Centric and Data-Centric halves of a logical object over the network.

There are many ways to serialize an object’s state so we can pass it from one object to another or from one computer on the network or the Internet to another. The approach we have found that works best at VantagePoint Software is a combination of dynamic string arrays (delimited string data) and serialized output from the Visual Basic Property Bag object. This is implemented within the base class server components of dbObjects.

Where we have object containment we need to expand the concept of state to encompass families of objects. This gets us to the concept of Combined state or a "SuperState." Combined state is the aggregate states of an object and the states of all other objects contained within the object, or what is referred to as object state stacking. For example, the Combined state or "SuperState" of a grandchild object with no additional children is the grandchild’s object state by itself. The Combined state of the Child object that acts as the Parent of the Grandchild object is the aggregation of the Grandchild object and all of its siblings along with the Child object. The Combined state of the top-level Parent object is its state along with the aggregation of each of its children and each of its children’s children or all the Grandchild object state. Stacking methods, serialization, and combined state management allows us to manage the state information within a family of objects as easily as the state of one object. This becomes critical when designing UI-Centric and Data-Centric business objects and this is implemented within the base class server components of dbObjects.

support@vpsoft.com