Thoughts on separating business logic from the framework, as a response for contractor shortage?

Need Help
1

Hi everyone,

The problem

There doesn’t seem to many CakePHP freelancers on platforms like Upwork, Fiverr and some local ones that I’ve tried. And for whom I found, it’s hard to tell if they are really invested into learning this exact framework and getting the most of it, or if it’s just one of the keywords they have on their profiles. I want them to know and be familiar with migrations, bake and other CakePHP-specific tools that I don’t know about.

Important: I’m not building a short-lived application, I intend to use it long term.

The (potential) solution

  • Move parts of my application from the framework to more widespread tools, e.g. cakephp/orm → Doctrine. Yes, I know that

    • @ADmad said the CakePHP ORM is damn good
    • @steinkel in the last month’s training session said it’s the best there is

    But I’m using this to illustrate the point because it’s easier to find (the arguably better) freelancers for doctrine than cakephp.

  • Implement the actual business domain using plain PHP

  • Connect to PHPUnit directly, dropping the CakePHP middleman layer

  • Keep using CakePHP for routing, templating (Layouts, Elements)

Sources

If it wasn’t for the following articles, I would have dismissed the above idea as fighting the framework.

And it all started here:

<…> your application is too tied to the framework, which in this case, can be a bad thing. Most frameworks want you to build your application using their tool.

The idea is to isolate your core app from the dependencies or try to strive for Clean Architecture. This is more work and may not be an option if you have strict deadlines.

Easiest example would be using SQL instead of ORM (I know, an unpopular opinion), or hide either way behind a mapper to your application’s business layer. You can further this by mapping to a POPO (Plain old PHP Object) Value Object or Entity class (not Doctrine, Cake, etc Entity). Using dependency injection you can change out the adapter to whatever is needed - the Mapper and subsequent calls to it don’t change.

The downsides that I can think of

  • Losing bake, although it can seemingly be replaced with code generators like Skipper 18
  • Over the last few years, CakePHP had been forcing me to be a better coder by imposing the stricter collective standards, while even if I hire some external plain PHP help, there will be noone to push us forward. Sure, there are the PSR standards, but then now you have to find someone who also follows their updates
  • The general feeling that an open source framework has much more hours and eyeballs invested in it, and dropping all that simply must be a bad idea

The question

This concept is very new to me, and I have never really thought about breaking down the framework, but now I can kind of see how it makes sense: you’re getting the best of all worlds, and at the same time you become locked in to a smaller extent. On the other hand, I’m not sure how much of this is actually a good idea, and how much of it will turn out to be reinventing the wheel. I am seeing a significant number of people voting in favour of this approach, but then again it’s the internet, and if you want to, you can find people arguing the Earth is flat.

So I’m looking for some common wisdom. Has anyone considered or attempted something like this?

Thanks for reading

3

In just two words: bad idea.