THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Alexander Kuznetsov

Should I Always Keep My Presentation Logic in My Presentation Layer?

Well I have just read a post by Jonathan Kehayias named

SQL Tip: Keep your Presentation Logic in your Presentation Layer

I cannot say I completely agree with it. Of course if all the following assumptions are true:

  • You already have a presentation layer
  • You are using only one presentation layer
  • Your client is good at formatting data
  • The expected half life of your presentation layer is no less than the expected half life of your database layer

 

then it indeed makes sense to do all the formatting in the presentation layer, and under these conditions I completely agree with Jonathan's post. However, any of these assumptions might not be true for your system, examples are provided below:

No presentation layer.

Suppose you need to export some data into a csv file, and you have some specific requirements on formatting dates and numbers. It is very easy to just format the data as you select it. IMO it is not feasible to write a presentation layer only for such a trivial task.

Also suppose that sometimes when you modify some very important data you need to generate an e-mail message and save it in a buffer table. Suppose that a job queries this buffer once every minute and sends out messages. In this case everything is so trivial that I would not build any presentation layer just for this simple task.

Multiple presentation layers

Consider a database used by multiple clients, some custom software written in C#, some other custom software written in Java, some C++ code running in Linux, etc. Doing one and the same task in multiple places is inefficient.

The client is not good at formatting

This is probably very rare but still may happen. For example, some specialized mathematical software is extremely slow in formatting dates.

The client will not stay around for a long time, but the database will

This is actually quite common - a well designed database may and frequently does outlive a client. The expected half life of your presentation layer is usually shorter than the expected half life of your database.

 

 

 

Published Friday, February 20, 2009 5:08 PM by Alexander Kuznetsov

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Jonathan Kehayias said:

Hey Alex,

Thanks for the follow up on this.  You are certainly correct, and I debated about putting link references to Forum posts that were examples that sparked blog post.  In almost every case, the final consumer is a single .NET application, web or winforms. Often is is a datagrid or a gridview, and the purpose in doing the formating in SQL is to simplify the application code so that it can be done entirely by the designer.  I can't fault someone for working like that, I used to.

I appreciate you doing a follow up and covering the additional information in this post.

February 20, 2009 5:55 PM
 

The Rambling DBA: Jonathan Kehayias : SQL Tip: Keep your Presentation Logic in your Presentation Layer said:

February 20, 2009 6:01 PM
 

AaronBertrand said:

On the multiple applications front, not only do you have cases where you need consistency across several apps you *can* modify (given unlimited time and money), there are also cases where some of your presentation layers are vendor products or off-the-shelf software which may suddenly interpret your data and present it differently...

February 20, 2009 8:33 PM

Leave a Comment

(required) 
(required) 
Submit

About Alexander Kuznetsov

Alex Kuznetsov has been working with object oriented languages, mostly C# and C++, as well as with databases for more than a decade. He has worked with Sybase, SQL Server, Oracle and DB2. He regularly blogs on sqlblog.com, mostly about database unit testing, defensive programming, and query optimization. Alex has written a book entitled "Defensive Database Programming with Transact-SQL" and several articles on simple-talk.com and devx.com. Currently he works at DRW Trading Group in Chicago, where he leads a team of developers, practicing agile development, defensive programming, TDD, and database unit testing.

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement