Overview

SingleObject is a lightweight framework (currently compatible only with PHP4) comprised by a single class, which provides:

  • a generic-object interface that supplies a layer of abstraction from the data
     
  • simple data persistence functions (based on the lesson taught by Ebay architectural changes)
     
  • a way to relate objects together (that is, some rudimentary ORM functions)

...all tied together in a very personal interpretation of Object-oriented programming, and of the MVC paradigm that aims to renovate the 3-tier software architecture scheme; and all built with three words in mind: performance, scalability, security.

Key benefits

  • speeds up development.
  • secure input/output handling
  • fast & lightweight
  • ...and lots lots more!

    •  

     

     

     

     

     

     

     

    Benefits

    Reduces complexity
    by removing the need to create an object (or nearly as much) per single table in the database.
     
    Makes development faster and easier
    by bringing business logic to a higher, more abstracted level.
     
    Makes source-code easy to understand
    Developers just need to know 1 object and its properties and methods.
     
    Makes development more concise and organized
    The software is self-contained. No external programs, no classes, nothing. Developers can only use 1 object. No more spaghetti code!
     
    Runs really fast
    It's overall about 900 lines of code, including comments, and it's always the same code being executed.
     
    Heaven for your scalability needs
    It's small and lightweight, and it's based on what I learned from reading about Ebay's architecture.
     
    Makes your application secure
    Input/output validation and sanitization is centralized and operated by the same object all the time.
     
    Has a database driven approach
    Add a field in a table in the DB, and it's automatically mapped for I/O at presentation (HTML) level.

     

    How it works

    SingleObject was coded as an experiment, so it's still in a very rudimentary form, however its mechanic is really easy:

    1) an init script builds a data-structure that represents the whole database with its tables, and a list of fields (included their properties) for each table. The variable which holds this, is $GLOBALS['singleobject']['map'].

    2) Then, every generic_object which is instantiated, references an index of this array, thus referencing a part of this data-structure, which is the table of the object with all its fields and properties. This job is all done by reference, and the variable that holds this reference is called $dbtable (it's a property of the generic_object).

    In other words: when initialized with the name of a table, the generic_object will simply "acquire" the structure of the table, so it will know which object it needs to represent.
    After you include the generic_object class into your code you can start treating your tables as objects right away, without doing the data-modeling.
    However, if you load the code in any kind of IDE with a debugger (phpED, or Eclipse, or php-IDE) it will be easy to see what's happening.

    I/O system

    The I/O system is simple, and divided in 2 layers.
    LAYER 1 - is the standard layer offered by PHP and relates to the data submitted via web-forms and held by the $_REQUEST members.
    LAYER 2 - relates to the data that reaches the inside of the objecct, which is held inside the property $data of the generic_object.

    Between layer1 and layer2 there is a filtering method that does this: by comparing the keys of layer1-array with they fields of $dbtable, it only fetches the data that belongs to the right objects, letting them pass to layer2.

    Input validation system is centralized: all input is validated by a method called validateall(), called by its relative interface-functions.

    Data-persistence & relational system

    The system is based on this rule: "database design should be as generic and abstract as possible".
    Database design is a very "mature" practice, but it's not questionable that many of the constraints that can make some code "sophisticated", come from likely sophisticated database design.
    Simple design is only limited to modeling the structure of the data-storage. Advanced design involves setting up relationships, in order to use SQL joins. Exotic design involves the use of stored-procedures and other devilish things.

    This presentation is a really valid excerpt of experience on field (it's from EBAY. period.) that shows how the use of joins and the use of stored procedures at database-level can make applications not scalable and not efficient at some point.

    SingleObject requires database design to use a simple "grammar" in order to encode some information within the names of the tables and the names of the fields - that is, to use some care in choosing the names, according to some criteria - and it also wants ER-modeling to be as simple as possible: tables should always have a numerical ID, and relationships should always be of the type many-to-many (because in this type, there is also included the one-to-many).