PHP 5 e-commerce Development- P8 pptx

This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Planning 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.
•
°
°
°
•
•
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010

953 Quincy Drive, , Brick, , 08724
Planning 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 reect 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 eld submissions), back to the controller. So we could also add the
•
•
•
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Chapter 2
[ 21 ]
web 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
VIEW
MODEL
WEB BROWSER
DATABASE
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 conrm a purchase with the customer

Interacting with the server's lesystem, for instance to upload photographs
of products
•
•
•
•
•
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Planning 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
VIEWS
FILESYSTEM
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 lesystem, the e-mail sender can access the e-mail templates
and also the systems mail program, the lesystem manager can access the lesystem,
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.
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724