Well I have just read a post by
Jonathan Kehayias named
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.