| home / programming / php_mysql2 / 1 |    [previous][next] |
|
|
|
Given these crude specifications for our objects, we could then implement them
and create a bizlogic directory and a number of .inc files that implement
the various classes needed for this functionality. If our UserManager
and User objects were sufficiently complex, we could create
a separate userman directory for them and put other middle-tier functionality,
such as payment systems, order tracking systems, or product catalogues into
their own directories. Referring back to Chapter 3, “Code Organization and Reuse,”
we might choose a layout similar to the following:
If we ever completely changed how we wanted to store the information in the database or how we implemented our various routines (perhaps our “Find User” method had poor performance), our user interface code would not need to change. However, we should try not to let the database implementation and middle tier diverge too much. If our middle tier is spending large amounts of time creating its object model on top of a database that is now completely different, we are unlikely to have an efficient application. In this case, we might need to think about whether we want to change the object model exposed by the business logic (and therefore also modify the front end) to match this, or think more about making the back end match its usage better.
Finally, in the middle tier of our web applications, we should change how we consider certain pieces of functionality. For example, if we had a certain set of rules to which something must comply, there would be an instinctive temptation to add PHP code to verify and conform to those rules in the implementation of the middle tier. However, rules change—often frequently. By putting these rules in our scripts, we have made it harder for ourselves to find and change them and increased the likelihood of introducing bugs and problems into our web application.
We would be better served by storing as many of these rules in our database as possible and implementing a more generic system that knows how to process these rules from tables. This helps reduce the risk and cost (testing, development, and deployment) whenever any of the rules change. For example, if we were implementing an airline frequent flyer miles management system, we might initially write code to see how miles can be used:
Any changes to our rules for using frequent flyer miles would require changing this code, with a very high likelihood of introducing bugs. However, if we were to codify the rules into the database, we could implement a system for processing these rules.
We will see more about how we organize our middle tier in later chapters, when we introduce new functionality that our business logic might want to handle for us.
Our final tier is the place without which none of our other tiers would have anything to do. It is where we store the data for the system, validate the information we are sending and receiving, and manage the existing information. For most of the web applications we will be writing, it is our database engine and any additional information we store on the file system (most notably .xml files, which we will see in Chapter 23).
As we discussed in Chapter 8, “Introduction to Databases,” and Chapter 9, “Designing and Creating Your Database,” a fair amount of thought should go into the exact layout of your data. If improperly designed, it can end up being a bottleneck in your application that slows things down considerably. Many people fall into the trap of assuming that once the data is put in a database, accessing it is always going to be fast and easy.
As we will show you in the examples throughout this book, while there are no hard and fast rules for organizing your data and other back end information, there are some general principles we will try to follow (performance, maintainability, and scalability).
While we have chosen to use MySQL as the database for the back-end tier of our application, this is not a hard requirement of all web applications. We also mentioned in Chapter 8 that there are a number of database products available that are excellent in their own regard and suited to certain scenarios. We have chosen to use MySQL due to its popularity, familiarity to programmers, and ease of setup.
However, as we show in Appendix B, “Database Function Equivalents,” there is nothing preventing us from trying others. And, having chosen a 3-tier layout for our web applications, the cost of switching from one database to another is greatly reduced (though still not something to be taken lightly).
| home / programming / php_mysql2 / 1 | [previous][next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: October 3, 2005
URL: http://webreference.com/programing/php_mysql2/1
