I have a design decision problem and would like to have some thoughts on it.
I’m building a CMS to use for my projects and want to incorporate existing components in it, like Doctrine, Monolog and any other i find suitable.
The question is, should I allow in code to access this each component directly, or should I have a buffer (proxy) class that acts as an API to underlying component?
In terms of performance/ease and access to full functionality i think it is better to allow this access, but in this case I lose control when component behavior changes (major version upgrade etc.). If I had a buffer class, i don’t lock myself to particular component, and even can replace it with another, while not breaking backwards compatibility, but in this case I have to almost duplicate code from the component (I mean, function from my buffer class calls functions from component)
The CMS is written in PHP, if that matters.
1
You need to weigh up each component and think about whether it really makes sense:
- You need to think about how likely it is that you will need to substitute one library with another. In the case of an ORM, you may want to substitute one RDBMS for another, but an ORM typically already provides that abstraction so it’s unlikely you’d also want to change your ORM.
- You need to think about how universal the API of your proxy would be. There’s no point crafting an intricate proxy API if you won’t be able to maintain that API in the event you switch a component. For example, you probably wouldn’t be able to maintain the same API if it is your intention to switch from an SQL to a no-SQL DBMS. On the other hand, it might be reasonable to drop in a different crypto library because most of those have similar functions and APIs.
- Would the effort of writing a new proxy layer actually be lower than just updating the main codebase? If a library deprecates a function or two every few years which are only used in a few places it would be hard to justify writing a proxy for the whole library in case a small number of those functions happen to change which would only take minimal effort to update in each instance any way.
As general examples:
- I probably wouldn’t proxy an ORM because an ORM is already an abstraction, it would add significant complexity to transform the data structures returned by an ORM into something generic, and I’m probably not going to have a compelling reason to switch.
- I probably would proxy something like a cloud object storage API, because it’s likely that I might want to use a different storage provider in future and they often have a similar or identical API.
Perhaps more important than their API is your API.
If:
- Your API is well defined, particularly in terms of what APIs are public and not
- Your API does a good job of encapsulating the libraries within (ie. it avoids exposing implementation/library specific constructs to external consumers)
- Your API is well covered by an automated test suite
Then even if you have to do significant re-plumbing of your application to replace a library or upgrade to a version with an incompatible API, you can at least be confident that your system still functions the same as it did before from an external perspective, and that you’re not passing these problems onto your users.
Why don’t you have a look (for example) at Symfony DBAL or Templating interface? If you want to provide components with different underlying extern implementation you will define your interface components and then provide a couple of adapters for those other libraries.
To keep it backward compatible simply don’t change the interface. If something for example Doctrine changes you can change the adapters.