Adding a new feature without needing to change much of
what already exists is, in itself, a good example of reusability.
Another advantage of the three-tiered architecture is that, if properly implemented, the
overall system is resistant to changes. When bits in one of the tiers change, the other tiers usually
remain unaffected, sometimes even in extreme cases. For example, if for some reason the
back-end database system is changed (say, the manager decides to use PostgreSQL instead of
MySQL), you only need to update the data tier and maybe just a little bit of the business tier.
Why Not Use More Tiers?
The three-tier architecture we??™ve been talking about so far is a particular (and the most popular)
version of the n-tier architecture. n-tier architecture refers to splitting the solution into a number
(n) of logical tiers. In complex projects, sometimes it makes sense to split the business
layer into more than one layer, thus resulting in architecture with more than three layers.
However, for our web site, it makes the most sense to stick with the three-layered design,
which offers most of the benefits while not requiring too many hours of design or a complex
hierarchy of framework code to support the architecture.
Maybe with a more involved and complex architecture, you could achieve even higher
levels of flexibility and scalability for the application, but you would need much more time for
design before starting to implement anything.
Pages:
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78