Saturday, June 14, 2008

Demystifying the n-Tier Architecture (Part 2)

As you begin to develop your applications, hopefully you start with a design.   The reason I say hopefully, is because many programmers think that a design is a waste of time, rather just a point of documentation.   In reality, design is a vetting of the idea prior to laying the application or enhancement's foundation.

Image what would happen if the carpenters started nailing boards together before an Architect designed the house.  Would design or idea look like the as-built version? I am highly skeptical that they would.  Well, the same thing occurs when a programmer starts writing code before a design has been created.

Once the design is completed and there is a clear understanding of what is being done within the application synchronously, asynchronously, where the transaction boundaries are, and other non-functional requirements like response-time, up-time, among many others.

Now we are ready to start discussion of the Tiers.

Tier 1.  Presentation and UI

Presentation layer can take on many forms.   XML, HTML, PDF, Word, Silverlight, WPF, Windows Forms, Crystal Reports, Microsoft Reporting Services, are just some of the examples of the presentation layer.   Although it is an obvious portion of the application it is an important aspect that still needs an honorable mention.

Rules of implementing a good UI layer:

  • Should not bind to database statement directly - rather use business and data objects to shuttle the data between the UI and the database.
  • Should not implement any business rules - One of the hardest point for a developer to grasp, what is a business rule anyway? Well, the business rule is something that runs the logic that is specific to your line of business that ensures data integrity.  The motions of the UI (hiding and showing controls) are likely not considered a business rule.
  • Instant feedback to user - once a user action is taken the user is assured that "we are working on what you have just asked".  The "whiteout" effect of paused UI while stored procedure is running should be a thing of the past.
  • Validation - As much of the validation as possible should be done a the UI level.
  • Know Your User - Appropriate views - Often the application developers create functionality just because it is cool, it is important to understand your customer/user.  Cluttered display of information is just as bad as lack of information.

In the world where most things services have been made a simple commodity, it is the presentation and the personal touch that will create a point of "differentiation" for your organization.  Once that happens, everyone wins.  Your company grows market share, you get promoted, get a bonus.  Believe me, it is a win worth the time...

In the next part of the series we will attack the "Business Objects"

Max

"Inspire, Imagine, Innovate"