Why spread business logic over three tiers?

Question

Hi there, I've just inherited a web-based travel request system to support and maintain. I can - more or less - follow the logic of it all, but I can't figure out why certain design decisions were made and I was wondering if you could help out. I've already discovered "Unobtrusive Javascript" as a result of this for example, so it could be a tactic I've just not read about before.

Case in point. Depending on about 8 different factors, each request requires emails sent out to one of four types of managers to authorise the request as well as other emails sent to people for information only.

• Client-side javascript keeps track of which manager type needs emails as the request is made so a person of that rank can be chosen to receive the email.
• Code behind the page plays dumb but saves only whether an email is required to be sent to each of the four manager types and the id of those selected. Not which type of email is to be sent.
• Finally, all mail sending is done in an Oracle Sproc which again recalculates all the emails to be sent out in which order and to whom along with which emails are information only and which are to ask for authorisation.

This seems a bit overly complex. Is there any reason (aside from keeping requests to the DB to a minimum) all the email logic, creation, and sending should be in one sproc and not in the code-behind of a page? Why repeat the same logic three times in three tiers?

Thoughts welcome.

Answer 1

You certainly don't want to repeat the same logic in all three tiers. But, a good separation of database from UI logic is always preferred. Putting it all together in one layer is not testable, for one. See Separation of Concerns (SoC) for more on that

Answer 2

"Why repeat the same logic three times in three tiers?"

There's no good reason. There are lots of bad reasons. You can do some software archeology to guess as to what bad reasons lead to this. Sometimes it helps to know why a mess was made -- for example, the architect could still have some influence and stifle your efforts to simplify.

Bad reasons include DBA's who insist that all business logic belongs in the database, no matter how unusable the app becomes. Or web designers that insist that all logic belongs as close to the user as possible (i.e., Javascript) no matter how huge the page becomes.

"Is there any reason (aside from keeping requests to the DB to a minimum) all the email logic, creation, and sending should be in one sproc and not in the code-behind of a page?"

The logic should be in one place, that's clear. Is a stored procedure the correct spot? That's debatable. See questions like Where are the Business Rules in MVC, Are the days of the stored procedure numbered?, Business Logic: Database or Application Layer.

Business logic belongs in a separate layer, independent of presentation and independent of persistence.

Answer 3

Well,

I would say that duplication of business logic over three tiers "can" be good for performance and better "user experience" (Web and/or WinForm).

Example: Imagine a business rule that says: the person's firstName must be between 2 to 100 characters.

• In the database, the field will probably a string (varchar/nvarchar) of max 100 chars. (in a sense, you just put a business rule in the database)

• In the DB tier, you could 'truncate' string over 100 chars.

• The application tier should absolutely have this check, of course, no doubt about that.

and in the UI, you want to provide automatic feedback to the user.

There's no reason to force the user to submit before returning an error saying that the string is too long !

Other examples: password + confirm password must match... well, it makes sense to have a check in the UI for a better User Experience, but you shouldn't neglect the necessity of having this check on the app tier.

So the UI must know about certain business rules in order to provide feedback as the user is editing the values.

There's a difference between "must spread business logic" vs "spread business logic where it makes sense".

Finally, there's a fine line between "business rules" and "validation rules". Validation rules make sense in the UI.