    |
|||||||||||||||||||||||||||||||||||||||||
        |
Distributed Application Design
Modern application design involves partitioning an application into multiple tiers; the user interface, a middle tier of business objects, and the data access tier. It may be helpful to identify the types of processing that we can expect an application to do. Most applications can, at least, do the following:
We can take these types of processing and generalize them into the previously mentioned three groups or tiers.
The dividing up of these application processes and distributing them among different client/server processes is known as Distributed Processing. Generalizing these processes into three categories or tiers is a logical effort and does not necessarily reflect any physical choices about computers, terminals, or other hardware. You can develop a client/server, distributed application based on these three tiers of Presentation, Business Logic, and Data Services and have the entire application run on one single computer. Alternatively, you can spread these tiers across a great number of different computers on a network. Either way, you have developed a logical 3-tier client/server application. dbObjects has been designed to support this approach to application design. While you can use dbObjects in a “fat” client with direct access to the database source from the user interface (UI), the real strengths of dbObjects are only fully realized when in a distributed environment. In addition to the generic database object that handles connectivity and command execution, dbObjects includes a library of base classes and templates that can be used in designing your presentation (UI) program, your business object servers, and your data services tier. These templates and base classes encapsulate a number of design considerations in developing specific objects for each tier of your distributed client/server application. The Presentation Tier
The presentation tier provides your application with a User Interface (UI). This is where your application is allowed to present information to the user and to accept input or responses from the user for use by your program. Ideally, the UI itself doesn’t perform any sort of business processing or business rule validation. Instead, the UI should rely on the business tier to handle those issues. This is important, especially today, because it is very common for an application to have multiple UI’s, or for your customers or users to request that you discard one UI and replace it with another. For instance, you may develop an application with a traditional GUI (a standalone Visual Basic program) and then be required to replace it with a browser-based UI, perhaps using Active Server Page (ASP) technology.
One of the most difficult and important factors when building a client/server application is to retain complete separation between the presentation logic and the business or data services logic. It is very tempting for developers to mix one or more tiers, putting some field validation or other business processing into the presentation tier rather than the business tier.
The Business Tier
Every application has code to implement business rules, business-related processing or calculations, and other business-related activities. Collectively this code is considered to make up the business tier. Again, one of the primary tenants of logical client/server design is that business logic should remain separate from both the presentation logic and the data services. This doesn’t necessarily mean that the business logic is physically somewhere else; rather your concern is that it is separate in a logical sense.
There are many ways to logically separate business logic. In object-oriented terms you would encapsulate the business logic in a set of objects or components that don’t contain presentation or data services code. Having logically separated your business logic from both the presentation and data services tier, you will gain significant flexibility in terms of where you physically place the business logic. For instance, you may choose to place the business logic on each client workstation, or opt to run the business logic on an application server, allowing all clients to access it as a centralized resource.
Business objects are designed to reflect or represent your business. They become a model of your business entities and relationships. This includes both physical objects and abstract concepts. Here are some examples of "real" world objects:
All of these are objects in the physical world, and the whole idea behind using software business objects is to create representations of these same objects inside your applications. Your applications can make these objects interact with each other just as they would in the physical world. For instance, an employee might create a work order to build a manufactured part from one or more purchased parts that are then sold to the customer. Following this logic you can create a work order business object that contains all the code it needs to manage itself – so you never need to replicate code to create work orders, you just use the object. Similarly, a customer object contains and manages its own data. A well-designed customer object can contain all the data and routines needed to represent a customer throughout an entire business and this can be used across all the applications for that business. Not all business logic is the same. Some business logic is very data-intensive, requiring fast and efficient access to the database. Other business logic doesn’t require frequent data access, but is often use by a robust user interface for entry field validation or other user interaction. If we want a robust, rich user experience we’ll need field level validation, screen level validation, and perhaps some real-time calculations or other business logic. We can consider this kind of business logic to be UI-Centric, since it is mostly used by the user interface. One solution that is used within dbObjects is to build on the client/server model and incorporate the concept of UI-Centric and Data-Centric business logic. By splitting the broad concept of a ‘business tier’ into two tiers, you can provide much more flexibility in your application design. dbObjects has base classes and templates to help you develop your own UI-Centric and Data-Centric business objects for your application. As an example, the UI-Centric half of a Customer object will provide properties and methods for use by the user interface developer. Examples may include properties for fields such as CustomerID, Name, Address, etc. and methods to create an invoice, file a complaint or other actions a customer might need to perform. The Data-Centric half of your Customer object would be responsible for behaviors that interact with the database, such as retrieving and storing the customer data. However, the Data-Centric behaviors may be substantially more complex – possible involving interaction with other data sources. For instance, you may also retrieve a map to the customer’s location. The Data Services Tier
Most applications interact with data, and store data in some form of database. There are some basic functions that are common to all data processing. These include:
Additionally, we typically have more advanced services available, such as searching, sorting, filtering, etc. These functions can be encapsulated in a set of objects that directly interact with both the Business Object tier and the actual data source.
Forward to dbObjects base classes and templates
For additional information or to order a copy of mvComponents Suite 2.0 and arrange for a consultant, please send an E-mail to: For VAR requirements and pricing please send E-mail to: |
||||||||||||||||||||||||||||||||||||||||
 |
|||||||||||||||||||||||||||||||||||||||||
Back to dbObjects Overview