Business Objects, cont’d…
So I’ve pitched building a library of business objects as the solution to transform about a million lines of VB code sitting in a hundred or so 7- to 10-year-old Access database applications into a valuable corporate asset of reusable code objects built using current technology.
The director of the IT department is not an IT guy but he has a great interest in sorting out the huge tangle of code he inherited with his job: it is expensive to maintain, difficult to secure, and is not easy to enhance. In short, it is a strategic liability.
Prior to me coming along, the solution has always been assumed that every application would simply be re-written in something else, that something else likely being Visual Basic dot Net. Since day 1 I have been lobbying against that approach in favor of analyzing the applications and consolidating the code under a set of centrally managed business objects as defined by the companies existing back-end data structures and their application needs.
In other words, I’ve proposed… get ready for the buzzwords… to build the middleware in a multi-tiered distributed database architecture. The task is daunting and to the casual observer may seem impossible but it is doable nonetheless. Though my boss is in charge of the IT department, I would consider him a casual observer so his response, as I had hoped and expected, was “show me.” We picked one of the more sophisticated MS Access database applications in the inventory and I am in the process of converting it to an n-tiered application using object oriented design and implementation.
Because I am having to write the code as well as do the design work, as well as support the current state of the beast, getting the design laid out has been a slower process than I am accustomed. The area I support is HR/Payroll along with all the supporting applications for time and attendance, manpower scheduling, and other personnel related activities so it was a no-brainer to start off by building the employee object first since every single application will at some point need to manipulate an employee’s data in some way.
As I’ve touched on before, these objects in the business tier are built separately from both the interfaces that utilize them and the objects that actually access the SQL data stores. Ideally the business objects are built to work independently of the consuming applications and the source of the data being manipulated. This is accomplished on the application side by defining a contract between the business object and the application that consumes it: if an application requests an employee from me under certain terms (the parameter list in the constructor call) I will return an employee object with certain information (the public properties and methods). No mention is made of what the application will do with the data nor does the business object disclose how the data is made available.
On the data access side, the business object becomes the consumer and has a contract with an object in the data access layer (an ADO.net connection object most likely.) If I know how to ask for something, say an employee’s punch history, the data access object will return the data without disclosing where it came from and without regard to what I am doing with it. We’ll get to security later.
Lets take an inventory of what we have so far towards this goal. We have a meta-data dictionary of all the VB code base that was created with the Access documenter utility we built. We have a simple DBConnection class to serve as a basic data access layer. And now we are starting on our first business business object: the employee.
Next time we will take a closer look at the employee object and decide what we need in there and what will be the best way to set up the design. We will also be tweaking our DBConnection class as we go along to take advantage of some of the very nice features of ADO, namely the typed dataset object which looks very unwieldy but one simply cannot ignore the power of the tools provided in the class.