Windows DNA - distinct layers
Evan Stein
Published: 18 Aug 2002 20:48 BST
Business logic layer
Only objects in the business logic layer could access objects in the data layer. This layer also acted as the link between the data layer and the user interface. For example, after inputting all the necessary data, the user would click a button indicating that the reconciliation was ready to be completed. The button click would be handled in the presentation layer, which would pass the reconciliation off to the Reconciliation object in the business logic layer (named ReconcileBL).
The object would validate the information, verify that the corporate general ledger balance equaled the department ledger balance plus the balances from identified missing transactions, and record the information in the application. Objects in this layer would call functions in the data layer objects to retrieve and store information but they did not interact with the database directly.
As with the data layer, as business rules changed (which I was certain they would), the code necessary to implement those changes would be confined to this level. A data validation rule could be updated or (as became the case later) rules on whether a reconciliation was complete or not could be added without affecting the presentation or data access layers.
Presentation layer
The presentation layer poses a particular challenge with Active Server Pages because the server-side scripting is entwined with the HTML output. To minimise confusion, we standardised on a layout for all ASP pages.
Each page was divided into three sections. All scripting code was located in the first section, event handlers (client or server side) were in the middle section, and the last section contained the output HTML (with a minor exception that I'll explain shortly).
The scripting code section was further subdivided. The first block of code would perform state checking and validation. This was necessary because of the inherent statelessness of HTML.
The second block would perform an algorithm, which would usually involve calling business logic methods to return data that would be displayed or passing form information to a business logic method so some function could be performed.
The third section defined output variables for any information that would be displayed in the HTML section. This action was done to minimise the script code that would be required between HTML tags.
The middle section of code defined all the event handlers. Differentiation between layers could get vague here. For example, if an input field value needed to have a minimal number of characters, was that presentation layer or business logic code? We decided to place all such code in the business logic layer. But because it would reside on the client side (as opposed to the server-side code discussed in the previous section), it would be implemented as ASP include files and related to the server-side objects by name. In other words, the server-side object for account handling was called AccountBL and the client-side business logic functions related to account handling would be defined in the file AccountBL_CS.asp. This modified the high-level model (see Figure C).
| Figure C |
 |
Note: There is no interaction between the client-side business logic functions and the data access layer. We kept all calls to the data access components in the server-side business logic components.
We went a bit further with the presentation layer and these steps also helped minimise the additional code and maintenance. On the HTML forms, we standardised the field names. The drop-down box listing all account numbers and titles was always called cmbAccountNumber. This drop-down was present on a dozen pages and was called cmbAccountNumber on every one. The on-click event handler was always called cmbAccountNumber_onClick().
Selecting an account number from this drop-down would display information about the account on that page. This meant making a call to the business logic Account object (AccountBL) to load the selected account, which would in turn make a call to the account data access layer object (AccountDL). Rather than putting these functions directly in the cmbAccountNumber_onClick() event handler, this code was put in the business logic include files. The cmbAccountNumber_onClick() handler would call a corresponding function in this include file; a change to this process would immediately become available to the Account Number drop-down box on all pages without having to make code changes on each page individually.
Summary
As expected, when the first version was released to the user community, interest began to grow. As interest increased, so did the number of functional changes required to make the application valuable to all departments. The largest change involved the page used to perform a reconciliation. We had designed a page that we thought contained all the information any department would need.
What we discovered was that even though the information was similar, each department used it in different ways. This went as far as one department reversing the meaning of the terms Credit and Debit because their initial department ledger had been incorrectly designed. The solution was to create an array of templates -- 15 in all -- one of which would be used to reconcile a particular type of account. We made considerable changes to the user interface. But because the logic behind a reconciliation wasn't changing and the underlying data structure was staying the same, only the code at the presentation layer needed to change. Imagine the hours of testing and retesting of the data access and business logic code that we saved because we didn't have to change that code.
After the project was complete, I did a rough calculation of how many extra hours were used up-front to implement this architecture vs. how many hours would have been required to implement the changes had we not layered the application code as we did. After all work was completed, I estimated that we actually reduced our overall development time by almost 35 percent by implementing the architecture the way we did. And although I haven't had the chance to verify it, I believe the final application was much more manageable and extensible than it would have been had we not been so diligent.
Have your say instantly in the
Tech Update forum.
Find out what's where in the new Tech Update with our
Guided Tour.
Let the editors know what you think in the
Mailroom.
Previous
Did you find this article useful?
25 out of 53 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
