OOP And The Datacentric Application.

This document will briefly examine the considerations for development methodology of a datacentric application and the suitability of some development tools.

Developing classes and objects for data access presents a dilemma in architectural design in that some clients want high performance, portability, scaleability and reliability for LOB data applications. They also tend to have a parsimonious nature and cast a wandering eye over Linux solutions (such as they are).

Most developers using Access / VB tend to use a procedural approach to working with data. Various newsgroup discussions regarding classes / objects indicated that seasoned developers played with them when they were first implemented but eventually could see no benefit in using them heavily. This is might be because the data access models supplied by ADO etc tend to 'objectify' their systems anyway. ???

If one contemplates tables and the relations it is obvious that it tends to be object oriented already.

One concept discussed occasionally is the idea of abstracting the datasouce from the business logic. Some consider the abstraction offered by DAO and ADO insufficient and would like to add their own layer which then uses these objects. This does however increase the amount of code considerably. It also, at first glance, seems to reduce performance and functionality. An example is the abstraction of the recordset class. The object has few if any dependencies on the SQL and entities / relations used so is fairly universal. But it offers no business data specific interface. The columns can be viewed as properties that change in number, type and application. A recordset object is significantly different from say a Customer or InventoryItem object where the 'columns' or properties are quite defined. One can also encapsulate business activities into an object as methods. A key point though is the loss of databound objects such as forms and reports etc.

A feature of an OOP is the intuitive nature of the coding experience. It can be pleasant to architect, craft and examine code using full OOP methods. In the example below we assume that the objects used do themselves call other objects that access the data (via ADO, ODBC) Thus, we abstract our datasource. This approach results in at about Six layers.

• Presentation
• Application Logic
• Business Logic
• Data Abstraction
• DataAccess
• DataStore

An example of some VB / VBA OOP code ...

Dim oBusiness as Business 
Dim Ocompany as Company 
Dim With Events oInventoryItem as InventoryItem 
Dim oWhareHouse2 as WhareHouse 
Set oBusiness = CurrentBusiness 
Set oCompany = oBusiness("Northrocks") 
Set oWhareHouse2 = oCompany.Wharehouses(2) 
Set oInventoryItem = oWhareHouse2.InventoryItems(oInvoice.Item) 
With oInventoryItem 
  .AutoBackorder = False 
  .Reserve 2 
  Select Case StockError.Number 
    Case UnderStock 
    If .ArrivalDays < 5 then 
      .Backorder 2 
      Else MsgBox 

One could derive the inventory item with default properties

Set oInventoryItem = CurrentBusiness("Northrocks")(2)(Invoice.Item)

See Also

For Each oLineItem in oInvoice.LineItems
  .oLineItem.Fill = Auto
  If .InventoryItem.Stock < .Ordered then
    If oCustomer.BackOrders = True and .InventoryItem.Backorders = True then
      .InventoryItem.Backorder(.Ordered - InventoryItem.Stock,oInvoice.Number)
      If.InventoryItem.ArrivalDays < 2 then .Annotate("Expected Daily")
    End If
  End If
End With

Given a tight spec for the object model, interfaces and logic it should not be difficult to port the above code to Delphi, Kylix or Java. (This also has the added advantage of true inheritance and resolves other issues with VBs poor OOP functionality.

However, with regret, I find that for datacentric applications there is a reasonable case for moving all the above logic into nested stored procedures on the SQL Server. Whilst structured / procedural SQL doesn’t approach OOP code like above for finesse and readability, it does remove the business logic from the client allowing a wider scope in client choice. A well crafted set of triggers / stored procedures / UDFs will remove the majority of code from the presentation layer (front end) and centralise business logic thus allowing very fast ports between Access, Delphi, VB.Net et al, as well as JSP (JDBC), ASP etc. By the same token, an object may have significant amount of procedural code in it's implementation (depending on the language).

The ‘down’ side is the perennial argument about abstraction and separation between the presentation, business logic and data layers. Combining the Business logic and Data layers in a single process appears to carry the risk of tight coupling (little or no abstraction). This will actually be true unless it’s accounted for. For instance adding or dropping a column on a table might require many changes in the SQL. However if we are able to ‘wrap’ the table in a view or procedure and only ever access the ‘wrapper’ we account for the changes in with wrapper. By Using SELECT * FROM BLAH we inherit the new column(s) (properties) from the base object (table). The wrapper can also account for complete table changes where we decide to further normalise the design (by linking in new tables) without causing a complete re-write. We also keep the ‘interface agreement’ with dependent objects by supplying or translating the deleted column in the wrapper. Thus, we can approach the OOP paradigm (abstraction, inheritance, encapsulation etc)

Then there is also the concern of changing SQL platforms. How hard is it to port TSQL to Oracle, Postgresql etc and how likely is that scenario (considering the expense of developing an OOP front end or middle ware / DCOM object to account for it happening?)
Another issue raised was that putting the bulk of the logic into the server would limit the scaling of the application. As the user count increased the server would soon loose headroom and bog down. I have not verified this.

With regard to developing a DCOM middle layer, it seems to me that Microsoft has gone cold on the idea (considering the hoopla in VB4 over the concept.) There is also the consideration that CORBA is not yet ready to fly so one would probably need to 'roll your own' IP based protocol and interfaces for this middle layer.

I would appreciate any thoughts and ideas regarding this dilemma.