Joe Chrzanowski

The DCI Paradigm

Created by Prof. Trygve Reenskaug DCI is the successor to MVC Originally intended to organize the

Model part of MVC Can be used as the basis for a web

development framework

DCI as realized by Prof. Reenskaug

The D for Data perspective specifies the system domain classes

The C for Context perspective specifies system operations A Context class defines this topology as a

network of interconnected Roles. A Context class defines methods that bind

Roles to objects at runtime. The I for Interaction specifies how

objects interact through Roles

Roles

Roles can be methodful or methodless Methodful roles are bound to objects at

runtime Implementing interfaces specifies roles

Roles define actual actions that objects can perform

Role methods are “injected” into objects that perform the given role

Example: Banker role can transfer money between accounts. Any object that implements Banker can transfer money

No inheritance required for roles

Example

Let’s say there are 2 account objects CheckingAccount SavingsAccount

Want to transfer $200 from Savings to Checking

Accounts must implement proper roles to perform the operations

Accounts alone are simply dumb data storage objects

Example (cont.)

Checking AccountTransferMoneyContext Plays role of

TransferMoneySource Needs to store a

balance

Takes 3 arguments Source Target Amount

Context tells TransferMoneySource role to move “amount” into a TransferMoneyTarget

SavingsAccount

Plays role of TransferMoneyTarget

Needs to store a balance

Checking account transfers as directed by TMCtx

Example (cont.)

Allows for a lot of interoperability Objects implement roles as necessary Any object implementing a specific role

can call role methods within contexts Potential downside

Variables must be implemented as public due to the way DCI objects interact with each other

Working on using __get/__set to allow for “private” variables – slower, but “better”

Example (diagram)

Classes are simply any class that can play Roles Roles provide interfaces to system operations Objects are the instantiated role-performing models

Implementation of DCI in PHP

Is the first (as far as I know) PHP implementation

Use interfaces to specify roles:interface SomeRole extends Role {}class RolePlayingClass implements SomeRole {}

Use static methods for Role actions Classname needs to be the Role name + Actions

class SomeRoleActions {

static function RoleMethod(SomeRole $src,$dst) {

/* …code… */

}

}

Implementation (cont.)

Use __call to simulate injection (send $this as $src)$roleclass = new RolePlayingClass();

$roleclass->RoleMethod($dst);

// same as RoleActions::RoleMethod($roleclass,$dst)

Allows for easy testing and RPC’s since role methods can be called in a static context

Base Framework Classes

DCIObject: defines a class that can play roles Model and Controller extend this object

Base Role interface (mostly for Type Hinting) DBCRUD Role(s) for DB Interaction

interface DBCRUD extends DBUser, DBCreator, DBReader, DBUpdater, DBDeleter {}

Demonstrates one role as a shortcut for several Interfaces are capable of multiple inheritance

Other roles View (renderable object- mostly for Controllers) DBModel (DCIObject that implements DBCRUD)

Exceptions

Using DCI for the Web

Want an extendable framework based off this concept

Controllers act as Context groupings Controller methods are essentially contexts Location where system operations are called In the form of VerbModelContext Example: FetchMessageContext (within Message

Controller)function fetch() {

return $messages->Read($this->get[‘id’]);}

Views are implemented as a role Controllers and Models can play the View role Allows objects to render (or return) themselves as HTMLecho $this->Render(“view.html”,$arguments);// orreturn $this->Render(“view.html”,$arguments);

Advantages over MVC

Implementing certain objects as roles allows for an easy (almost automatic) plugin system Plugin provides roles, objects are designed to play

the roles and implement the functionality Can be implemented at runtime via $obj->AddRole Can be implemented at compile time via implements

Context execution Contexts don’t contain any real application logic,

only relational mapping Most testing of system operations can be done directly

through the static role methods Also allows AJAX calls without initializing the whole

environment (= faster) AjaxController to return responses as JSON instead of

HTML

RESTful Routing

DCI provides interesting opportunities for applications using REST routing

In theory, would allow for routing like /context/src/dst/argument/argument/argument /src/roleaction/dst/argument /role/context/src/dst

Would demonstrate the exact application function in the URL Like MVC, but points to the actual code instead of the

function that calls it Provides a map to specific code location where

the action is executed (which role) Transparent controllers? (Low priority, topic for future work)

Framework Feature: Wax Blocks Method of creating any sort of plugin, theme, roles,

or other resource Manually instantiated

Provides easy access to the block’s resources Searches ./ first, then the global plugin directory:

/wax/blocks$block = Wax::LoadBlock(“sampleblock”); $block->stylesheets[‘something.css’];$block->roles[‘rolename’];

Blocks contain different types of resources Images Stylesheets Scripts Roles and Contexts (controllers) Misc. Objects

Blocks are just groups of resources, no need for init code

Basic Application Structure Resources.wax

Base resource package for the app Contains

Header and footer code Theme information including images and

stylesheets Global application scripts

Index.php Set up routing Headers/Footers

Other Blocks One per model Contains models, controllers , views, and

resources for it

Live Example

Simple message board Demonstrates

CRUD Operations Views Example of DCI Wax Blocks

http://localhost/wax/examples/messageboard