How to Produce a Rich Domain Model with Active Record

Introduction

What is the Active Record (AR) pattern?

My implementation of Active Record

Issues with Kevin Smith's article

It's not an ORM

Each table column must be a separate property

Cannot make a property private

Complex validation rules

The AR pattern determines the system architecture

Summary

References

Comments

Introduction

I recently came across an article written by Kevin Smith called How to Produce a Rich Domain Model with Active Record in which his opening statement was:

You can't. It's not possible.

Active Record provides complete access to a database row's fields through an object's public properties (or "attributes" of an "Active Record model", as they're called in both Ruby on Rails' and Laravel's ORMs). Any part of the codebase can access those attributes to read or change any of the data in the database row, making it easy to start working with a real database in your code.

The trouble starts when the complexity of the business inevitably reveals itself and you need to restrict the inherent permissiveness of Active Record to ensure that information is only retrieved or modified according to the rules of the business. In other words, you need a rich domain model: a layer of the codebase where the expressiveness of the business is encoded into a community of collaborating objects, each properly bounded and equipped with the information and behavior they need to model the relevant interactions and responsibilities of the business.

I completely disagree with this statement as I have been using my version of this pattern for the past 20 years, and I have never encountered any of the problems which he identifies.

This is almost identical to the rebuttal I gave in Active Record: Getting it Right to Shawn McCool's article called Active Record: How We Got Persistence Perfectly Wrong.

The fact that both of these people had problems with their implementations of this pattern speaks to the failure in those implementations rather than the pattern itself. A Design Pattern fits the following description:

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations.

This makes it quite clear that a pattern describes WHAT needs to be done but not HOW it should be done. Different programmers using the same language could produce different implementations of a pattern, but that is completely irrelevant. Provided that the code follows the description of the pattern and produces the expected results then it is a valid implementation. There is no such thing as a single definitive implementation that every programmer should follow, a valid implementation that makes every other implementation automatically invalid. The success or failure of a pattern's implementation is down to the skill of the implementor, so if there are problems with an implementation then they must be due to the lack of skill shown by the implementor.

What is the Active Record (AR) pattern?

The Active Record pattern is described by Martin Fowler, the author of Patterns of Enterprise Application Architecture (PoEAA), as follows:

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.



An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.

In wikipedia this pattern has the following description:

The active record pattern is an approach to accessing data in a database. A database table or view is wrapped into a class. Thus, an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated, the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.

This pattern is commonly used by object persistence tools and in object-relational mapping (ORM). Typically, foreign key relationships will be exposed as an object instance of the appropriate type via a property.

My implementation of Active Record

Before I switched to using PHP in 2002 I had no knowledge of design patterns, OO "best practices", or those design principles such as SOLID. I had spent the previous 20 years in writing enterprise applications using COBOL and UNIFACE, and neither of these languages had "best practices". Each team I had worked in had its own set of programming standards which were completely different from those used by every other team. The idea of a "one size fits all" set of standards simply did not exist.

With COBOL I was used to developing monolithic single-tier programs, while UNIFACE v5 introduced me to the 2-tier architecture as all database access was handled by a built-in database driver. When UNIFACE v7.2 was released it introduced support for the 3-Tier Architecture with its Presentation, Business and Data Access layers. I liked this so much I used it as my starting point for my PHP development. This was relatively easy as programming with objects is naturally 2-tier by default - after creating a class with methods and properties you must have a separate script which instantiates this class into an object so that it can then call its methods. Because I also started off by generating all HTML using XSL stylesheets, for which I wrote a single reusable object, I effectively split my Presentation layer into two giving a Controller and a View as described in the MVC Design Pattern as shown in Figure 1:

Figure 1 - 3-Tier Architecture combined with Model-View-Controller

Working on many different database applications taught me several lessons which I follow to this day:

• In a database application the most important part is the database - get this wrong and you will feel like you are swimming against the tide.
• The software structure should follow the database structure - get this wrong and you will feel like you are swimming against the tide.
• While every table holds different data their structure follows the same rules and they are all subject to the same CRUD operations.
• Every database application consists of a number of user transactions (use cases) and every one performs one or more operations on one or more tables.
• The code for a user transaction never exists in just one place - it requires a group of collaborating objects each with different responsibilities. A Controller receives a user request and translates this to method calls on one or more Models; a Model may call a Data Access Object to communicate with the database. After the Model(s) have finished executing their data is extracted and given to the View object so that it can be rendered into HTML.
• Some user transactions are quite similar to other user transactions, with the only difference being the identity of the table which they work on.

I learned PHP by teaching myself by reading the online manual and looking at sample code in the books which were suggested in newsgroup forums. I learned about encapsulation and inheritance, but did not see any examples of polymorphism. I saw some ideas which I liked, some which I did not, and experimented with some ideas of my own. My goal was to produce as much reusable code as possible as that was the best way to become more productive. An enterprise application is made up of a variable number of subsystems, each with its own database and user transactions, so I looked for ways to deal with a growing number of database tables and user transactions to deal with those tables. Despite being totally unaware of the Active Record I developed a solution which had some similarities and some differences:

• I built a separate class for each database table to hold the business rules for that table.
• I started with just four methods to deal with the standard CRUD operations.
• I decided not to create separate class properties for each table's columns as I recognised that it would be far easier to get data into and out of an object using a $fieldarray variable, thus removing the need for large numbers of getters and setters.
• In order to identify which columns existed on that table and their validation rules I decided to store this information in a separate $fieldspec variable.
• Because each table class now had a $fieldarray variable and a $fieldspec variable I was able to write a standard validation object which could take the two arrays and check that the value for each column matched its specifications. This meant no more hard coding of basic validation.
• Instead of limiting each object to just a single row I found it easy to deal with multiple rows as my decisions to pass all data around in an associative array meant that I could easily convert it to an indexed array of associative arrays.

After constructing my first table class, the Model in the MVC design pattern, I then built a separate Controller for each of the user transactions in this family of forms. Once I had got these working I created a duplicate set for the second database table. This resulted in a lot of duplicated or similar code, so using what I had read about inheritance I decided that the best way to share this duplicated code was to move it to an abstract table class which could then be inherited by every concrete table class. At the end of this exercise I had a lot of code in the abstract class and nothing inside each concrete class except for its constructor. Note that I do not have separate validate() and store() methods which the Controller can call as they are called internally from within the abstract class, as shown in Common Table Methods:

$fieldarray = $this->pre_insertRecord($fieldarray);
if (empty($this->errors) {
  $fieldarray = $this->validateInsert($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->commonValidation($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->dml_insertRecord($fieldarray);
  $fieldarray = $this->post_insertRecord($fieldarray);
}

$fieldarray = $this->pre_updateRecord(fieldarray);
if (empty($this->errors) {
  $fieldarray = $this->validateUpdate($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->commonValidation($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->dml_updateRecord($fieldarray);
  $fieldarray = $this->post_updateRecord($fieldarray);
}

$fieldarray = $this->pre_deleteRecord(fieldarray);
if (empty($this->errors) {
  $fieldarray = $this->validateDelete($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->dml_deleteRecord($fieldarray);
  $fieldarray = $this->post_deleteRecord($fieldarray);
}

$where = $this->pre_getData($where);
$fieldarray = $this->dml_getData($where);
$fieldarray = $this->post_getData($fieldarray);

Alongside these common methods are a set of common table properties:

A more complete description can be found in Abstract Table Class.

As stated previously I was able to create a standard validation object to take care of all primary validation, but what about any additional business rules known as secondary validation? Because I was using an abstract table class I was able to implement the Template Method Pattern which meant that I could add custom code into any concrete table class simply by adding code into one of the available customisable "hook" methods.

For my set of six Controllers the only difference was the name of the class from which the object was instantiated (remember that I did not need any setters and getters for individual columns), so I decided to extract the definition of the class name into a separate component script which then passed that name down to the Controller. This meant that while each user transactions had its own component script they could each share one of the standard Page Controllers.

I do not insert any methods into any concrete table class to deal with object associations. My previous experience taught me that regardless of what type of relationship you have to deal with they are variations of the standard one-to-many or parent-child relationship which can be deal with in a uniform way by using a special Transaction Pattern which deals with the handling of the foreign keys between those two entities. Referential Integrity can also be dealt with by standard code which is built into the framework. Object Aggregation also becomes a non-issue.

Originally I constructed the contents of the $fieldspec variable by hand, but as this became tedious due to the rising number of database tables in my application I decided to automate by building a Data Dictionary into which I could import each table's details directly from the database schema, then export it to create a separate table structure file as well as the table class file. Originally I used to construct each component script by hand, but then I added extra functionality into my Data Dictionary so that I could select a table, link it to a Transaction Pattern, press a button and have the script(s) created for me. This amount of code generation greatly increased my productivity.

As you can see I have taken the bare bones description of the Active Record pattern and refactored it to produce a sophisticated and comprehensive implementation which is far superior to anything else I have seen.

Issues with Kevin Smith's article

I shall now comment on some of the statements made in Kevin Smith's article which I find questionable, and explain how I have circumvented some of the issues which he has raised.

Active Record is not an ORM

Active Record provides complete access to a database row's fields through an object's public properties (or "attributes" of an "Active Record model", as they're called in both Ruby on Rails' and Laravel's ORMs). Any part of the codebase can access those attributes to read or change any of the data in the database row, making it easy to start working with a real database in your code.

The idea that the AR pattern is used to produce an Object Relational Mapper (ORM) is just an erroneous opinion, not a fact that is cast in stone. In Martin Fowler's Catalog of Patterns it is not categorised as being any sort of mapper which is reserved for those cases where the object structures and the relational structures do not match. Besides, an ORM is a service, not an entity. The difference between the two is that a service is stateless and does not contain any business rules while an entity has state and does contains business rules. This is confirmed in Active Record Basics where it says:

Active Record is the M in MVC - the model - which is the layer of the system responsible for representing business data and logic.

This is also confirmed in Martin Fowler's description which clearly show several methods which retrieve current state. This proves that the object is stateful and is therefore an entity, and not stateless, in which case it would be a service.

Each Model, one for each entity in the application, sits in the business/domain layer. An ORM or equivalent Data Access Object (DAO) sits in the Data Access layer. In my implementation there is no need for any mapping between two different structures simply because the structures are never different.

Each table column must be a separate property

Active Record provides complete access to a database row's fields through an object's public properties (or "attributes")

Having separate class properties for each table column, each with its own setter (mutator) and getter (accessor), has never struck me as being a good idea for database applications, although it may be appropriate for other types of application. If you think about it there are two possibilities:

1. An object only has one possible set of values (properties or attributes) and those values appear individually and separately. In an aircraft control system, for example, the software is only dealing with a single aircraft, and each of its sensors (air temperature, air pressure, air speed, altitude, et cetera) sends in its current reading on its own without waiting for it to be assembled with the readings from other sensors. The software processes all these readings in real time and sends the results to the instrument panel in the pilot's cockpit.
2. An object such as a database table has separate values for each row. A database deals with datasets which may contain values for any number of columns and any number of rows, and for each row there can be any number of columns. The User Interface (UI) or Presentation layer, which in a web application is an HTML document, also deals with datasets and not one column at a time. When an HTML document is constructed before being sent back to the client device it contains all the values it needs - it is not fed them one variable at a time. When the user presses a SUBMIT button the entire contents of that HTML document are posted to the server in a single $_POST array - they do not appear one variable at a time.

Can you see the difference between the two? One deals with a single object (aircraft) which has a single set of values which are fed in from different sensors at different times. This means that separate properties with their own getters and setters are appropriate. The other deals with the contents of a database table which deals with datasets which can have any number of columns from any numbers of rows, and some of those columns may be for/from other database tables. Each dataset is handled in an input or output operation as a single unit (an array) and not individual pieces. This means that separate properties with their own getters and setters are NOT appropriate.

If the data coming into and going out of an object appears in the form of sets which may contain values for any number of columns from any number of rows from any number of tables then how is it possible to justify building software which restricts that data to a fixed set of columns from a single row of a single table. This sounds like an artificial restriction just to obey an arbitrary rule which was devised for a different set of circumstances. Deconstructing each dataset into separate pieces of data so that you can use a separate method to read or write each piece of data using code similar to the following would, to me, be a prime example of tight coupling (which is considered to be bad):

<?php 
$dbobject = new Person(); 
$dbobject->setUserID    ( $_POST['userID'   ); 
$dbobject->setEmail     ( $_POST['email'    ); 
$dbobject->setFirstname ( $_POST['firstname'); 
$dbobject->setLastname  ( $_POST['lastname' ); 
$dbobject->setAddress1  ( $_POST['address1' ); 
$dbobject->setAddress2  ( $_POST['address2' ); 
$dbobject->setCity      ( $_POST['city'     ); 
$dbobject->setProvince  ( $_POST['province' ); 
$dbobject->setCountry   ( $_POST['country'  ); 

if ($dbobject->updatePerson($db) !== true) { 
    // do error handling 
} 
?> 

This also means that if you change the number of columns then you have to change some method signatures as well as all the places which call those signatures.

Contrast this with the following code which demonstrates loose coupling (which is considered to be good):

<?php 
require_once 'classes/$table_id.class.inc';  // $table_id is provided by the previous script
$dbobject = new $table_id;
$result = $dbobject->updateRecord($_POST);
if ($dbobject->errors) {
    // do error handling 
}
?> 

If you look at Common Table Methods you will notice that I load all the data into an object as a single array argument on the method call without having to name any of its component parts. This means that I can vary the contents of this input array at will without any adverse consequences as the validation which is automatically performed within the method will reject any input which is not completely valid. Note also that the same array is used as both an input and output argument on every internal method call so that the contents of the array can be amended, but only by a method which belongs inside that particular object.

Accessing a piece of data using $fieldarray['column'] is no different from $this->column, so there is no loss of functionality but there is an increase in the advantages.

Extracting the data from an object, such as when transferring it to the View object, does not require a collection of getters as it can be done with one simple command:

$fieldarray = $dbobject->getFieldArray();

Another reason which caused me to reject the idea of having a separate class property for each column, each with its own setter and getter, is that it restricts each object to only being able to deal with columns on that particular table.

• Long experience has shown me that some input screens contain data that needs to be split across several tables, so how can you utilise setters on a Model for those columns which do not exist as properties within that Model? With my method you can put whatever data you like in the input array, and the operation will only fail if the data required by that Model fails its validation checks. Any data which does not belong on that table will be ignored, but can be handled in the relevant "hook" method, such as _cm_post_insertRecord() or _cm_post_updateRecord().
• Long experience has also shown me that sometimes an output screen requires data that comes from several tables, not just one, so how can you utilise getters on a Model for those columns which do not exist as properties within that Model? With my method you can build a SELECT query which will retrieve as little or as much data as you like, which includes the results of expressions as well as JOINs.

Cannot make a property private

Need to make a property private so that only the object has access to it, a fundamental principle of software design called information hiding? It's not possible.

Firstly, I do not consider that implementation hiding, which is totally different from information hiding, requires the use of any visibility declarations. Simply hiding the implementation behind an interface (which is what ALL software does, not just OO software) has always been good enough for me. I built my framework using PHP 4 which did not have any of these visibility options, and my code worked without any errors, thank you very much. When I upgraded to PHP 5 and became aware of these options I simply could not justify the effort of changing my code as there would be no measurable benefits.

As explained above in Each table column must be a separate property I do not have a separate property for each column, so I simply do not have this problem. Once you have called an operation such as insertRecord() or updateRecord() with its input array you cannot change the contents of the array from outside the object, only from the inside.

Complex validation rules

Need to require multiple pieces of information for an update and validate them before accepting the changes, like making sure you have both longitude and latitude before updating geo-coordinates? Sorry, you can't enforce that.

Every experienced programmer knows that all input data must be validated before it is written to the database otherwise the DBMS could reject the data. This requires code to be executed within the object, but the questions that needs to be answered are What code do you write? and Where do you put it?

As stated earlier Active Record is the M (Model) in MVC so it is responsible for all data validation and business logic. This means that all validation rules need to be accessible from within the Model. If you look at Common Table Methods you will see that the insertRecord() and updateRecord() methods each call their own internal validation methods before attempting to update the database. Two separate types of validation are performed:

• Standard validation - this verifies that each piece of data is valid for that column's specifications in that database table, such as a numeric field must contain a number, a date field must contain a date, a NOT NULL field cannot be empty while a NULL field can, et cetera. As each column's specifications are available in the $fieldspec array within the Common Table Properties this means that this validation can be performed automatically by the framework's standard validation object without any intervention by the developer.
• Non-standard validation - This cannot be performed automatically as the business rules are specific to each Model class and therefore need to be inserted into each Model class by the developer. This is where my use of an abstract table class shows its benefits as it enables the use of the Template Method Pattern which has any number of "hook" methods. These are defined in the superclass but do nothing, but they can be redefined in any subclass to do something which is relevant only to that subclass such as in the following example:

  function _cm_commonValidation ($fieldarray, $originaldata)
  // perform validation that is common to INSERT and UPDATE.
  {
      if ($fieldarray['start_date'] > $fieldarray['end_date']) {
          // 'Start Date cannot be later than End Date'
          $this->errors['start_date'] = getLanguageText('e0001');
          // 'End Date cannot be earlier than Start Date'
          $this->errors['end_date']   = getLanguageText('e0002');
      } // if
  
      return $fieldarray;
  }
  

  Some other frameworks prefer to use callbacks, but that's only because they either cannot use or don't know how to use "hook" methods.

  The best you can do is apply business rules in domain services that wrap the Active Record model, but you can't actually enforce the rules anywhere. This is the critical, inescapable problem with using Active Record in the domain. Nothing is stopping the rest of the codebase (or worse, third-party packages) from bypassing your constraints to manipulate the data directly. And make no mistake, that will happen. The inevitable outcome is data corruption, inscrutable bugs, and feature development slowing to a crawl as you try to regain stability in your system.

  I'm sorry, but if you write code that allows that, then shame on you! You MUST write code that enforces the business rules, and you should put those rules in the proper place which is in the business/domain layer.

  There is nothing in Martin Fowler's description which says that this pattern MUST NOT perform any data validation, or that all data validation MUST be performed in another object, so it left to the developer's discretion. If you don't include the necessary validation before the database is updated then you have no right to complain if that update fails or, even worse, stores invalid data. Don't complain if you allow some other part of the codebase to bypass your constraints.

The AR pattern determines the system architecture

By its very nature, Active Record's impact on a domain cannot be contained and thus will largely determine the resulting system architecture, despite whatever plans its developers may have at the outset.

If you had designed your system architecture to be multi-layered, as I did, then built each component to conform to its position in that architecture, then you would not have a problem. My Controllers, Views and DAOs are pre-built and supplied within the framework, and all Models are initially generated by the framework to follow a standard pattern. All the sharable protocols, which includes all standard validation, are inherited from an abstract class, and the only code the developer has to add is the custom logic which can be inserted into any of the available customisable hook methods.

Given enough time under real-world dynamics, it will lead to a big ball of mud that becomes increasingly expensive to maintain.

I could not disagree more. I built my current framework 20 years ago and constructed an abstract table class after noticing the common protocols and common properties after building just two concrete table classes. I used this framework to build my first ERP application in 2007 using the designs for the PARTY, PRODUCT, ORDER, INVOICE, INVENTORY and SHIPMENT databases from Len Silverston's Data Model Resource Book. The prototype was finished in 6 man-months, which works out at an average of just one man-month for each database. I later upgraded this to a much larger ERP application which now contains 20 subsystems, 450+ database tables, 1,200+ relationships and 4,000+ user transactions, and I have never encountered any of the issues which Kevin Smith mentioned.

As for being difficult and expensive to maintain, that is not the fault of any particular design pattern but the developer's ability to implement them correctly. In recent years I have upgrade my ERP application to include the following:

• I changed 4,000 HTML forms to have a responsive web interface in just over 1 man-month.
• I added the ability to exchange data with collaborating organisations using a private blockchain in just over 1 man-month.

Does that sound like a Big Ball of Mud to you?

Now you could try to contain Active Record to the edge of your application, only using it as a conduit between your database and domain objects that properly enforce the necessary constraints. This would keep it out of your domain and go a long way toward avoiding architectural distortion.

How you use the AR pattern is up to you, but if you use it incorrectly or in the wrong place then how can you say the pattern itself is at fault? I use it, as do others, as the conduit between the Presentation and Data Access layers, which means that it is the Model in MVC. As such it is the only layer in the entire system which contains and enforces all business logic, and once a method has been called by a Controller on a Model it is physically impossible for the input data to be corrupted by an external object. If I can do it then anyone can.

Summary

The final statement in his article goes as follows:

To put it plainly: Active Record fundamentally cannot allow the enforcement of constraints on its objects, leaving you with no option but to apply all your business rules in services and therefore "completely miss the point of what object-oriented design is all about" and "incur all of the costs of a [rich] domain model, without yielding any of the benefits".

If your interpretation of the "rules" of OOP causes you to write software and then complain about the results which it produces there as only two possibilities as far as I can see:

• Either: the rules are questionable/sub-optimal.
• Or: your interpretation of the rules is questionable/sub-optimal.

If your implementation of a design pattern is not producing satisfactory results then perhaps you have chosen the wrong pattern, or perhaps your implementation of that pattern is incomplete or flawed. You should also be aware that it is not good practice to pick a design pattern and then write the code to implement it, you should first write code that works and then refactor it as necessary to remove any duplications and see if any patterns emerge. This is not just my opinion, it is also the opinion of Erich Gamma, one of the Gang of Four, who in How to Use Design Patterns said:

Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns.

Some people say that the AR pattern produces an ORM, which makes it a stateless service, while others say that it is the M in MVC, which makes it a stateful entity. It can't be both, so which is it? In my implementation of this pattern it is used as the Model, not an ORM. If you have used it as an ORM then you should have put your business logic into an object which exists in the business/domain layer, and this object should only pass control to the ORM/DAO once all the business rules have been processed. If your business rules are not being processed then that can only be an omission on the part of the developer and no fault in any pattern pattern.

Here endeth the lesson. Don't applaud, just throw money.

References

The following articles describe aspects of my framework:

• RADICORE - A Development Infrastructure for PHP at tonymarston.net
• The RADICORE Security Model at tonymarston.net
• The Model-View-Controller (MVC) Design Pattern for PHP at tonymarston.net
• Transaction Patterns for Web Applications at tonymarston.net
• A Role-Based Access Control (RBAC) system for PHP at tonymarston.net
• User Guide to the Menu and Security (RBAC) System at tonymarston.net
• A Data Dictionary for PHP Applications at tonymarston.net
• Creating an Audit Log with an online viewing facility at tonymarston.net
• An activity based Workflow Engine for PHP at tonymarston.net
• UML diagrams for the Radicore Development Infrastructure at tonymarston.net
• Internationalisation and the Radicore Development Infrastructure (Part 1) at tonymarston.net
• Internationalisation and the Radicore Development Infrastructure (Part 2) at tonymarston.net
• RADICORE - Implementing Virtual Private Databases at tonymarston.net
• RADICORE for PHP - Functions, Methods and Variables at tonymarston.net
• FAQ on the Radicore Development Infrastructure at tonymarston.net
• RADICORE for PHP - creating PDF output at tonymarston.net
• The Template Method Pattern as a Framework at tonymarston.net
• Evolution of the RADICORE framework at tonymarston.net

The following articles express my heretical views on the topic of OOP:

• Design Patterns - a personal perspective
• Object-Oriented Programming for Heretics
• Design Patterns are dead! Long live Transaction Patterns!
• What is Object Oriented Programming (OOP)?
• Not the three greatest paragraphs ever written on encapsulation
• Table Oriented Programming (TOP)
• A minimalist approach to Object Oriented Programming with PHP
• Using object composition for "has-a" relationships is not such a good idea
• OO Design is incompatible with Database Design
• How NOT to Validate Data
• Object Oriented Database Programming
• Let's Make It More Complicated Than It Really Is Just To Prove How Clever We Are
• What is the difference between Procedural and OO programming?
• The difference between an interface and an abstract class
• Having a separate class for each database table *IS* good OO
• Why I don't do Domain Driven Design
• The concept is OK but your implementation is not
• Re: Objects should be constructed in one go
• Re: What's so great about OOP?
• To There and Back - but still in the wrong place
• Re: Exceptions and talking back to the user
• Are you achieving the aims of OOP?
• Pop Quiz on OOP
• RE: The purpose of inheritance is code reuse
• Fat Model, Skinny Controller
• How to decouple business logic from UI logic
• From Oop to Poop, from Excellent to Excrement
• The database is NOT just an implementation detail
• Active Record: Getting it Right
• The meaning of "abstraction"

These are reasons why I consider some ideas to be complete rubbish:

• Case Sensitive Software is EVIL
• Software Patents are EVIL
• Stored Procedures are EVIL
• Object Relational Mappers are EVIL
• Dependency Injection is EVIL
• Not-so-SOLID OO Principles
• Singletons are NOT evil
• Getters and Setters are EVIL
• Object Interfaces are EVIL
• Object Associations are EVIL
• Inheritance is NOT evil
• I fail to GRASP these principles
• Namespaces are for numpties
• The case against static typing in PHP
• The case against overloading in PHP

Here are my views on changes to the PHP language and Backwards Compatibility:

• Breaking Backwards Compatibility is EVIL
• Please do not break our language
• BC break in 7.2 caused by undocumented and unauthorised change
• Changing fundamental language behaviors
• Is PHP too verbose?
• RE: Improving PHP's Object Ergonomics
• The PHP core developers are lazy, incompetent idiots
• Is there a case for adding namespaces to PHP core?
• The case against static typing in PHP
• The case against function overloading in PHP

The following are responses to criticisms of my methods:

• What is/is not considered to be good OO programming
• In the world of OOP am I Hero or Heretic?
• Your code is crap!
• On not using the "right" standards
• Your rules are RUBBISH!

Here are some miscellaneous articles:

• Component Design - Large and Complex vs. Small and Simple
• How to handle a Many-to-Many relationship with PHP and MySQL
• A class for validating and formatting dates
• Customising the PHP error handler
• Technical Keys - Their Uses and Abuses
• Pagination - what it is and how to do it
• The Relational Data Model, Normalisation and effective Database Design
• Development Standards - Limitation or Inspiration?
• Saving PHP's Session data to a database
• Are you a Code Monkey?
• The Singleton Design Pattern for PHP
• Working with a stateless protocol
• A flexible method of storing control data
• Web Site vs Web Application
• Using Radicore components in a front-end website
• An end-to-end eCommerce solution requires more than a fancy website
• Database Design - are you Novice, Ninja or Nincompoop?
• Why you should build your web application back-to-front
• Why PHP is not suitable for enterprise grade web applications