MVC is a relative new term in web development. The whole MVC philosophy is on how to organize code on the server (PHP, Ruby, JSP etc.), and how to separate the various function in development. A short summary of MVC is to separate server code in three groups.

  • MODEL: A layer to manage data retrieval and storage. Keeping data structures and the direct modification of these.
  • VIEW: A layer for generating visual data. That is generating HTML, Scripts, XML and the like of some predefined data structure.
  • CONTROLLER: The connecting structure between the HTTP call, the data and generating views. A "perfect" controller function has three steps, (1) deciding what data to load. (2) Load them, and (3) show them.

And added to that we also have:

  • LIBRARIES: Global classes and function library where we put what's not really belongs any of the above groups. Can be data caches, access control, translation system etc.

I still don’t have much experience with MVC, but what I’ve used so far (code igniter, and a touch if RoR and Zend), but the difference from programming all in one block is huge.

My last project in Market Monitor is to make a dynamic access control system fit for our internal structure, which became a full fledged RBAC (Role Based Access Control) system. And it wasn’t really difficult either. Using the MVC structure, it was easy to separate the various functions, and to build a set of library classes to manage users, roles and resources. In addition to the groups and the ACL.

This contains:

Database relations: For the time being, using the MySQL database, but should be programmed in a general SQL97 syntax, so it’ll be DB independent.

  • auth_roles: Roles overview.
  • auth_subroles: Roles in role graph. Note: This must NOT become circular.
  • auth_groups: Group overview.
  • auth_grouproles: Groups can have roles associated with them.
  • auth_users: Users, passwords and user information.
  • auth_userroles: Which users have which roles (directly)
  • auth_resources: Resources (with hierarchy)
  • auth_acl: The Access Control List (user or role to allow or deny).

And a model class (UserDAO for loading and storing the data here, should possibly be renamed “AuthDAO”). And library classes:

  • Role: A simple role container.
  • User: A user container. Changes some behaviour regarding users, and separated users from roles (needed in the authorization process to prevent too much recursion).</li>
  • Resource: The resource tree, and with the core authorize method.</li>
  • Auth: Library class for storing authentication data and methods. Simplifies most authorization to a single line: if($auth->authorize("$resource_path")). The only requirement, loading an instance of Auth, and having a login possibility.</li>

And most important of all… A controller for administering of the authentication system. Managing roles, groups, users and resources, dependent of the admin’s rights. Be it system administrator or some group administrator.

This system implements in total a complete Role Based Access Control system, and with relative little code. Some 2000 lines in total, spread on 6 classes, and some utility functions. Too bad I’m leaving that workplace. Would really like to see how this system is utilized, and to be allowed to work on it further.