Figure 2-3. Example of information exchange among application tiers
The Right Logic for the Right Tier
Because each layer contains its own logic, sometimes it can be tricky to decide where exactly
to draw the lines between tiers. In the previous scenario, instead of reading the product??™s
quantity in the business tier and deciding whether the product is available based on that
number (resulting ultimately in two database calls), you could have a single stored procedure
named add_product_if_available that adds the product to the shopping cart only if it??™s available
in stock.
In this scenario, some logic is transferred from the business tier to the data tier. In many
other circumstances, you might have the option to place some logic in one tier or another or
CHAPTER 2 ?– LAYING OUT THE FOUNDATIONS 18
maybe in both. In most cases, there is no single best way to implement the three-tier architecture,
and you??™ll need to make a compromise or a choice based on personal preference or external
constraints.
Furthermore, there are occasions in which even though you know the right way (in respect
to the architecture) to implement something, you might choose to break the rules to get a performance
gain. As a general rule, if performance can be improved this way, it is OK to break the
strict limits between tiers just a little bit (for example, add some of the business rules to the data
tier or vice versa), if these rules are not likely to change in time.
Pages:
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76