PHP – How to Avoid Code Repetition in CRUD Operations

dryobject-orientedPHP

I'm developing a PHP application and I find myself doing basically the same code for, say, creating an object based on a form filled by the user.

The objects are of different classes, but the process is mostly the same: take the data from the form, apply validation, save/return error.

Is there a way to automatize this process? I ask also because I intend to write a public API and use the same code to do those operations, instead of just copy/pasting.

I thought of making a kind of Factory Method pattern that receives the type and the data from the form (or any array), create an instance and set the data, testing the validation afterwards (each object knows how to validate their own fields). And that for each of the other CRUD operations as well.

Is that feasible/good practice? Should I just repeat the similar code? There are any other way to do it?

For the record, I'm using ORM already (Doctrine). Still, I think that a lot of create functions with pretty much the same code (a bunch of set*) is something too repetitive.

Best Answer

If you're not already using an ORM, you're probably doing it wrong, because you're not taking advantage of the leverage that an ORM can provide to the practice of writing CRUD methods.

However, there's a bit of history to all this, so I'm now going to tell you a little bedtime story.

In the beginning, there were SQL databases, and life was good. Web sites were pretty sparse little affairs, and everyone got along by writing data access code by hand.

Then the wolly mammoths came.

enter image description here

No, not that wooly mammoth.

This woolly mammoth. Databases that encompass an entire business domain:

enter image description here

Suddenly, data access code written by hand didn't cut it anymore. So we invented ORM's, code-generation programs that produced one class for each table, complete with CRUD methods. It's a lot of code, but you didn't have to write it, did you?

Great story, huh bro? Well, not exactly.

You see, someone came along and said "Why do I need to know database theory, when I could just write my classes and then have the ORM generate my tables for me?"

OK, but now you're gonna have to write all of those classes by hand, aren't you?

Which brings us to the question you asked, which essentially is this: why can't I just write a function that accepts a type T, and returns an object of type T, like this?

public T Read(int id); // C#, for those of you so challenged.

Sigh. Well, you can, actually. It's called a Generic Repository. If you want to find out how to build one, you can look here. It starts with something like this:

public function select($table, $where = '', $fields = '*', $order = '', $limit = null, $offset = null)
{
    $query = 'SELECT ' . $fields . ' FROM ' . $table
           . (($where) ? ' WHERE ' . $where : '')
           . (($limit) ? ' LIMIT ' . $limit : '')
           . (($offset && $limit) ? ' OFFSET ' . $offset : '')
           . (($order) ? ' ORDER BY ' . $order : '');
    $this->query($query);
    return $this->countRows();
}

...and builds on that humble beginning (and other functions to round out the CRUD) to create a complete generic repository. Add some IoC to it, and you'll have something that any Architecture Astronaut would consider worthy enough to take to interstellar space.

Related Solutions

Coding Standards – Validation of Input Parameter in Caller: Code Duplication?

It depends. Deciding where to put validation should be based on the description and strength of the contract implied (or documented) by the method. Validation is a good way to bolster adherence to a specific contract. If for whatever reason the method has a very strict contract, then yes, it is up to you to check before calling.

This is an especially important concept when you create a public method, because you are basically advertising that some method performs some operation. It better do what you say it does!

Take the following method as an example:

public void DeletePerson(Person p)
{            
    _database.Delete(p);
}

What is the contract implied by DeletePerson? The programmer can only assume that if any Person is passed in, it will be deleted. However, we know that this isn't always true. What if p is a null value? What if p doesn't exist in the database? What if the database is disconnected? Therefore, DeletePerson does not appear to fulfill its contract well. Sometimes, it deletes a person, and sometimes it throws a NullReferenceException, or a DatabaseNotConnectedException, or sometimes it does nothing (such as if the person is already deleted).

APIs like this are notoriously difficult to use, because when you call this "black box" of a method, all sorts of terrible things can happen.

Here are a couple of ways you can improve the contract:

Add validation and add an exception to the contract. This makes the contract stronger, but requires that the caller perform validation. The difference, however, is that now they know their requirements. In this case I communicate this with a C# XML comment, but you could instead add a throws (Java), use an Assert, or use a contract tool like Code Contracts.
```
///<exception>ArgumentNullException</exception>
///<exception>ArgumentException</exception>
public void DeletePerson(Person p)
{            
    if(p == null)
        throw new ArgumentNullException("p");
    if(!_database.Contains(p))
        throw new ArgumentException("The Person specified is not in the database.");

    _database.Delete(p);
}
```
_{Side note: The argument against this style is often that it causes excessive pre-validation by all calling code, but in my experience this is often not the case. Think of a scenario where you are trying to delete a null Person. How did that happen? Where did the null Person come from? If this is a UI, for example, why was the Delete key handled if there is no current selection? If it were already deleted, shouldn't it have been removed from the display already? Obviously there are exceptions to this, but as a project grows you will often thank code like this for preventing bugs to permeate deep into the system.}
Add validation and code defensively. This makes the contract looser, because now this method does more than just deletes the person. I changed the method name to reflect this, but might not be necessary if you are consistent in your API. This approach has its pros and cons. The pro being that that you can now call TryDeletePerson passing in all sorts of invalid input and never worry about exceptions. The con, of course, is that users of your code will probably call this method too much, or it might make debugging difficult in cases where p is null. This could be considered a mild violation of the Single Responsibility Principle, so keep that mind if a flame war erupts.
```
public void TryDeletePerson(Person p)
{            
    if(p == null || !_database.Contains(p))
        return;

    _database.Delete(p);
}
```

Combine approaches. Sometimes you want a little of both, where you want external callers to follow the rules closely (to force them to code responsible), but you want your private code to be flexible.

///<exception>ArgumentNullException</exception>
///<exception>ArgumentException</exception>
public void DeletePerson(Person p)
{            
    if(p == null)
        throw new ArgumentNullException("p");
    if(!_database.Contains(p))
        throw new ArgumentException("The Person specified is not in the database.");

    TryDeletePerson(p);
}

internal void TryDeletePerson(Person p)
{            
    if(p == null || !_database.Contains(p))
        return;

    _database.Delete(p);
}

In my experience, concentrating on the contracts you implied rather than a hard rule works best. Defensive coding appears to work better in cases where it's hard or difficult for the caller to determine whether an operation is valid. Strict contracts appear to work better where you expect the caller to only make method calls when they really, really make sense.

Design Patterns – How Aggregate Root and Repository Pattern Solve DRY in Database Operations

They don't.

Those concepts reduce or centralize the number of calls your business code needs to load any data objects by calling CRUD code directly, but actually the CRUD code to load or update or save the objects still has to be somewhere, since it is used, at least, from inside the repository.

You reduce the need of writing such boilerplate by using code generation techniques, an ORM or some kind of Micro ORM which generates the CRUD code either ahead-of-time or just-in-time. But this is mostly orthogonal to the Repository Pattern or the Aggregate Root concept.

Best Answer

Related Solutions

Coding Standards – Validation of Input Parameter in Caller: Code Duplication?

Design Patterns – How Aggregate Root and Repository Pattern Solve DRY in Database Operations

Related Topic