0% found this document useful (0 votes)
68 views

Planning An E-Commerce Framework - Part - II: By: Muhammad Zeeshan Ali

The document discusses the registry pattern and singleton pattern in the context of planning an e-commerce framework. The registry pattern provides a means to store shared objects like database handlers and user data retrievers. A singleton pattern ensures only one instance of the registry is available. The document also proposes a file structure for the framework with separate folders for models, views, controllers, and registry objects.

Uploaded by

sania ejaz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
68 views

Planning An E-Commerce Framework - Part - II: By: Muhammad Zeeshan Ali

The document discusses the registry pattern and singleton pattern in the context of planning an e-commerce framework. The registry pattern provides a means to store shared objects like database handlers and user data retrievers. A singleton pattern ensures only one instance of the registry is available. The document also proposes a file structure for the framework with separate folders for models, views, controllers, and registry objects.

Uploaded by

sania ejaz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Planning an e-Commerce

Framework – Part - II
By: Muhammad Zeeshan Ali

1
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.

2
Registry …
• 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

3
Registry …
– 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

4
Registry …
• 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.

5
Registry …
• Let's have an overview of the registry pattern:

6
Registry …
• 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 …

7
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.

8
Singleton …
• 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.

9
Structure
• The next important stage in the design of our framework
is its structure.
• We need to design a suitable file structure for our
framework.
• We need the structure to provide for:
– Model
– View
– Controller

10
Structure …
– Administration Controllers
– Registry
– Registry Objects
– User/administrator uploaded files
– Third-party libraries
– Any other code

11
Structure …
• Taking this framework structure into account, a suitable
directory structure would be as follows:
– Models
– Views
• View A (that is, a folder per set of views)
• Templates
• Images
• JavaScript

12
Structure …
– Controller
• Controller A (that is, a folder per controller)
• Controller Admin
– Registry
• Objects
• Database Objects
– Uploads
• To be expanded when we add products and images to our framework!
– Libraries
– Miscellaneous
13

You might also like