In this chapter, you will learn: About design and architectural patterns in PHP, including: Model-View-Controller Registry Singleton How to structure an extendable framework How the fram
Trang 2Planning our Framework
Now that we know more about what we are here to do, it is time to start planning
our framework to ensure we get it off to the right start In this chapter, you will learn:
About design and architectural patterns in PHP, including:
Model-View-Controller Registry
Singleton How to structure an extendable framework
How the framework should work with settings for the site and e-commerce
setups it powers
Let us start by designing our framework, and then building it based on our ideas for
its design
Designing a killer framework
There are many different ways to design and build frameworks Some
involve building very complicated frameworks, and others involve creating
simple ones In this book, we are going to quickly build an easy-to-use,
easy-to-understand framework
This book will serve as a guide to help you develop a framework of your own,
different from the one created in this book, but better suited to your needs, ideas,
and preferences The emphasis in this book is on e-commerce, so if you already have
a framework of your own, or would prefer to use an existing framework, this book
will give you ideas to integrate e-commerce capabilities into any framework
•
°
°
°
•
•
Trang 3Planning our Framework
[ 20 ]
Patterns
There are a number of design and architectural patterns that were designed to help
provide some general, good practices and solutions to common problems within
software design There are a few patterns of particular interest to us, as we are
looking to develop a framework:
Model-View-Controller (MVC)
Registry
Singleton
Model-View-Controller (MVC)
The Model-View-Controller architectural pattern provides a widely used solution
to separate the user interface from the logic of an application The user interface of
the application (view) interacts with the data (model) using the controller, which
contains the business rules needed to manipulate data sent to and from the model
To put this into an e-commerce perspective, consider a customer adding a product
to their shopping basket clicks on an Add to basket button within the view/user
interface The controller processes this request and interacts with the model (basket)
to add the product to the basket Similarly, the data from within the basket is relayed
back to the user interface through the controller, to display how many products are
in the basket, and the value of the contents
CONTROLLER
VIEW MODEL
Because we are creating a framework for use with websites and web applications, we
can further extend the representation of the MVC pattern to reflect implementation
in such a framework As discussed earlier, the models represent data; this is
primarily stored within the database However, in our framework we will have
a series of models, which take the data and store it within themselves in a more
suitable format, or allowing the data to be manipulated more easily So, we could in
fact add our database to this diagram, to show the interaction with the models and
the database We are also viewing the end result of our website or web application
in a web browser, which renders the views, and relays our interactions (for example
mouse clicks or field submissions), back to the controller So we could also add the
•
•
•
Trang 4web browser to the diagram, to show its interaction with the views This gives us a
clearer understanding of how the MVC pattern will work within our framework, and
where the three components sit within it
CONTROLLER
Registry
The registry pattern provides a means to store a collection of objects within our
framework The need for a registry arises from the abstraction provided with the
MVC pattern Each set of controllers and models we create (for example products,
shopping basket, page viewing, or content management) need to perform some
shared tasks, including:
Querying the database
Checking if the user is logged in, and if so, getting certain user data
Sending data to the views to be generated (template management)
Sending e-mails, for instance to confirm a purchase with the customer
Interacting with the server's filesystem, for instance to upload photographs
of products
•
•
•
•
•
Trang 5Planning our Framework
[ 22 ]
Most systems and frameworks abstract these functions into objects of their own,
and ours will be no exception A registry allows us to keep these objects together
The registry can then be passed around the framework, providing a single point of
contact to access these core functions Let's have an overview of the registry pattern:
DATABASE HANDLER TEMPLATE MANAGER EMAIL SENDER FILESYSTEM
MANAGEMENT
REGISTRY
REST OF THE FRAMEWORK
MAIL PROGRAM
AUTHENTICATION HANDLER
The framework interacts directly with the registry, which provides access to the
other relevant objects These objects can interact with one another using the registry
itself, and have functionality to interact with aspects of the system they require; that
is, the database handler can access the database, the template manager can access the
templates stored on the filesystem, the e-mail sender can access the e-mail templates
and also the systems mail program, the filesystem manager can access the filesystem,
and the authentication handler reads and writes to session variables and cookies to
maintain an authenticated user's session throughout their visit to the site
Singleton
There are certain situations where we may require an object to only ever have one
instance of it available For instance, we will make use of a database handler and
multiple instances of this could lead to results from different queries being supplied,
depending on how it is used The singleton pattern is designed to prevent this from
occurring, by restricting an object to one instance only
However, we won't use the singleton pattern in this way We will instead use it to
ensure we have only one instance of our registry available in the framework at any
point of time