Changing the Architecture.

I’m not a keen on the idea of dumping all my code in the web server root directory, so I tested the framework flexibility by rearranged the application structure a little.

	-rw-r--r--   1 Capfile
	drwxr-xr-x  14 application
	drwxr-xr-x   3 config
	drwxr-xr-x  13 system
	drwxr-xr-x   5 public

Once these locations were updated in the application configuration files it all worked perfectly. The reasons for doing this sort of thing have been documented elsewhere, and I agreed with them from this security standpoint, however this structure also fits better with Capistrano deployment.

A positive first impression.

The Views deal with the presentation logic, and I like the fact that embedding PHP within the HTML is the default, instead of a complex templating system. It’s not the cleanest approach, but I prefer to have full control over my HTML.

As for the Controllers, the implementation is quite intuitive and you can build a friendly set of URLs with a little help from mod_rewrite and the URI class.

The form validation is a great feature that I found easy to implement within the Controllers and Views. I’ve centralised my validation rules in the global configuration file suggested in the documentation, but haven’t got the automatic rule group feature to work yet.

The Model class is used to represent a single database table. I’m used to mapping tables with a Class in this way, but normally each instance would represent a row of data. CodeIgniter Models implement the Singleton design pattern, only one instance per class, from which the Database class methods can be called.

The Database class provides the data access layer and a good set of robust methods which return an array of stdClass instances representing the resulting data rows. These arrays are then forwarded to the View, where the instance variables can be directly accessed. This is quick and easy, but not very OOP.

Implementation reservations.

I believe that the Model should be capable of running as a stand-alone application, once equipped with any interface, even the command-line. It’s this level of autonomy that results from the MVC design pattern: substitute a different Controller and View and it’ll still work the same way on a different platform.

Controllers reacting to events, whilst Views shouldn’t have direct, mutable access to instance variables. The Model should encapsulate both the data and the business logic, not something that can be effectively achieved with Singletons alone. Indeed CodeIgniter blurs this distinction by making Models optional and allowing data manipulation directly in the Controllers.

I’ve implemented my preferred approach by providing my own classes to replace the stdClass. They don’t extend the CodeIgniter Model class, but are instantiated within those that do, encapsulating data and business logic; including Object–relational data mapping and CRUD functionality.

It works well, but I’m concerned that by introducing a more rigourous approach I’m losing some of the advantages of the framework. May be I would be better to take CodeIgniter at face value, as a flexible, if a little dirty, rapid development environment that works.