E-Commerce Framework Part 2

by Mike Willbanks on August 2nd, 2007

Since my previous post about the lack of an e-commerce framework generated quite a difference about frameworks, I decided to clarify and also explain some of my thoughts and ideas that an e-commerce framework should hold. These thoughts and ideas may be a little rough around the edges but I wanted to give a definition to the meaning of what I feel a framework is in this case as well as items that would potentially be a part of this framework.

The following definition adequately defines what I feel a framework should entail:

A software framework is a reusable design for a software system (or subsystem). This is expressed as a set of abstract classes and the way their instances collaborate for a specific type of software.
Source: Wikipedia

I feel it should be a “library” so to speak of reusable elements. These elements would then have the ability to be abstracted, extended and implemented depending on the various functionality which is a large problem within present design of many e-commerce [platforms|carts|etc].

Components should entail basis needs and then be allowed to be extended for edge cases. We are attempting to solve the basic problem, not the problem with edge cases. The problem with edge cases are handled on an individual basis and helpers could be created in order to do so (even while maintaining OOP practices).

Payment processing and courier handling are the two major components. Since they are utilized in many different services from a service oriented company to a physical oriented company or a little of both.

Payment Processing:
This would be in the form of a factory class to load the specific module, you could then create 2 sets of classes, one for the response and one for the request. Many times the request will initiate the response in the form of an API but in terms of paypal these two object may not be coupled. Both the request and response objects would either build off of an interface or an abstract class.

Courier Handling:
This is almost exactly the same as the payment handling except you would have one more class for the handling of packages. Packages can be defined by the physical boxed shipment. In the case of a shopping cart these would most likely be coupled to the items that would be for purchase depending on how the items might be packaged. Therefore we end up with a request, response which uses packages and you might have something that calculates what can fit into each package. Remember, each package might not ship at the same time and might be used over multiple couriers. So packages would most likely need an interface or abstract class to handle how each package might work.

With these objects you may want to also want to take the time to create an address object that handles users addresses so each payment gateway and courier can correctly map each address to the proper locations.

Now, if you are wanting to get into the course to fill out this framework more we can start to add items that may require the usage of different types of storage such as a db, flat file, xml, etc.

Catalog (or categories, which may display multiple times in a hierarchy)
Item (which may have multiple attributes so you would have attributes that would go out – remember items may not be physical items)
Item Package (different ways that items might be grouped together to create a single item)
Pricing (this can become extremely complex when you get to discounts and tiered rates)
User (typically containing critical user details, so this is usually up to each platform but a single baseline object may help them get speedy results)
Address (this would tie to each user if a user object was created)

There are several other items, feel free to add to this list if you feel so compelled. This is what I was meaning by a framework. No UI’s just libraries of code that allow a developer to fully customize their process without changing procedural code. I as a developer do not want to use your crappy procedural code, crappy template engine or anything else. I will handle the system the way I want to with the library as I see fit. A library/framework should help me get to the end result faster without limiting what I can do in terms of the process I would like to do a project.

From PHP

  1. idont permalink

    A framework is *not* a library of classes. A framework includes a library of class in your case.

    But just a few (free) tips: 😉
    1.- Technical framework have a bright future. Business frameworks have rarely been a success story.
    2.- Focus on the technical part not business/e-commerce process….
    3.- Do not build your project as a framework.
    4.- Build your project as a component. It should be a black box without outside dependancies.

  2. I agree with most of your remarks. While most business frameworks have not been successful they definitely could be if there was enough support for them. You handle the technical aspects of how things should be handled and leave many of the items up to the developer.

    I would never build this as a separate framework, I would utilize a pre-existing framework such as the Zend Framework. There is no point to creating a separate entity. In essence much of what OOP practice and design attempts to do is compartmentalize each piece.

  3. Once again Mike your hitting the the nail on the head. I hope we at the PRADO Community Project will be able to get something like this together for PRADO.

  4. idont permalink

    The issue with business framework is that they have to match the business processes. And almost no company want that for their core activities or the other ones.
    Think about SAP which is a sum of business exceptions: all the companies wanted their business requierments added. You have seen the mess over time….

    Focus on the technical part.

    Keep it simple. :)

  5. The issue with business framework is that they have to match the business processes. And almost no company want that for their core activities or the other ones.

    This is primarily the reason to keep it technical. For instance if you look at the layout it would provide baseline functionality that would allow for easy extensibility. Business logic is not truly implemented but the core functionality that would allow for business to implement based on an OOP pattern to be more simplistic.

    If we are looking at this from a developers perspective, there are components that are easily pluggable to implement certain types of things. I continue to feel this is mostly the payment and courier support that is by far the most important.

    What a business would then do is utilize the components to give them a base and then extend and build in their requirements.

  6. Once again I point out the project I’m working on. Spurred into action by your previous post, I should have a more proper release out later this week.

    It has some of the things in it that you have pointed out here, and some of the rest I had already decided to put in at a later point (honest!)

    Take a look, and let me know what you think…. version 0.2 will be better.

  7. Steve W permalink

    I’ve been noticing the need for something like this for years. I’d be interested in helping out with the payment processing portion of this project. What I need for the e-commerce projects I develop is a single interface to a sub-system that can handle multiple payment methods. The component should be portable enough to be plugged into any custom php e-commerce application, but flexible enough to meet the checkout and configuration needs of any new shopping cart.

    Is work already being done on a similar payment processor? How can I get involved?

Trackbacks & Pingbacks

  1. PHPDeveloper.org
  2. developercast.com » Mike Willbanks’ Blog: E-Commerce Framework Part 2

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS