Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


Tip of the Day
Language: Enterprise
Expertise: Advanced
Jul 5, 2000

Designing Tiers and Placing Business Rules in Them

Sometimes in a multi-tier system, designers tend to follow rigid object-oriented design rules to perform heavy data-centric manipulations in the middle tier. Remember, a thin line separates the operations that the middle tiers should handle and those that the database should handle. One should judge with care where the operation logically belongs, while keeping in mind the performance benefits of alternative approaches. I have seen design teams waste a lot of resources and energy deciding whether to have such operations in the middle tier or in databases (data storage and services).

For example, it makes more sense to me to perform complex joins between different tables at the database level and get the desired recordset back to the middle tier. An object model may toy with the idea of having many "Gets" (such as making various simple selects on each table) using separate data access component operations, with each one bringing data from a particular table. While more object oriented, this approach results in unwanted data in the middle tier and extra processing to retrieve the desired record set from this chunk. These can be avoided altogether with the previous approach.

To stress again, using stored procedures as much as possible further enhances performance. Using stored procedures also helps in the basic aim of any design: to separate the business logic from the data storage.

Jai Bardhan
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date