لطفا منتظر باشید ...
Assessment of Needs and Requirements in the Real World
You'll often find that hard-core academics of programming science insist that an n-tier architecture is the only correct way to build an application. Although I can see that point pretty clearly (after all, I am writing this book), we all know that the real world has a lot of variations on correctness.We've talked about a few of the benefits of the layered architecturenamely, that it's easier to maintain and understand. However, just as you shouldn't implement object-oriented programming for the sake of doing so, you shouldn't build these layered or tiered applications just for the sake of doing so.Consider the scope of the application you're building and the business problem you're trying to solve. If you need to bang out a two-page application that collects contact information into an Access database, chances are you won't need to break out the application into four or more layers. Even the POP Forums application could have been consolidated by combining the data access layer and the business rules layer. (You'll see an example of this combination in the next chapter.)It's not uncommon for your requirements to include the ability to process huge amounts of data. This kind of requirement will force you to divvy up the application because it will spread the workload across more than one machine. When the database server is on a physically separate machine, that means the database server CPU and the Web server CPU can be dedicated to doing their own tasks.
