In a multitier business solution, the most common three tiers are as follows:
The user-interface tier typically resides on each user's workstation; the
business-rules or business-logic and data-access tiers more often reside on a network server.
You can use ActiveX with VB to create COM components that implement business
logic in the solutions that you develop.
The objects provided by COM components to implement business logic are often known
as business objects. You might, for example, provide a business object to the system in the
form of a COM component that gives credit information and performs credit validation for customers.
When designing your system, you need to determine where components for the business-logic
tier should reside and what the best form of implementation should be.
The first question to ask when designing a business-logic tier is this: "How
should the tier be implemented?" Some possibilities might include the following:
-
Implement as part of the user interface (compiled into that tier's executable).
Although this might be the easiest to program in the beginning, it would quickly
become a maintenance nightmare. Every time that your company changes the way it
does business, you would need to make a change to the application and then distribute
it to all the users. An email with a note to please rerun the install would probably
not be sufficient—if a business rule changes, it should change for all users
at the same time; it would be hard to count on all users to implement the change
at, say, 12:00 a.m. on a particular date.
-
Implement as part of the system's data structure (a trigger or a stored procedure).
This would eliminate the problem of having to update every user's workstation.
Such a choice will almost certainly confuse the functions of any data tiers and
the business- logic tier, however. The business-logic tier would not be a separate
unit and so couldn't be easily separated from the data when needed. This solution
also impedes scalability. What would happen, for instance, if the data itself
were someday split into more than one database? Business rules would have to be
distributed among those databases. If any business rules were duplicated between
the databases, they would have to be maintained in two places.
-
Implement as a COM component on a server. This solution would provide the most
long-term stability for maintainability and scalability. It would guarantee that
future changes to the business rules would only require maintenance in one place.
It would also guarantee that upward scaling of the system to accommodate more
users or increased resources for reasons unrelated to business rule changes would
not require changes in the component or its implementation.
