Let's say I'm developing a web application. My first choice is to use PHP with Fat-Free Framework (F3) and MVC pattern. Next year, I might decide I want to switch to Zend Framework, or maybe even ASP.NET MVC. Does it make sense to try and design my application in such a way that it is loosely coupled to its framework, or is the framework too integral to make this realistic?

The only reason I ask is because it came up in conversation with a peer recently, who criticized my pie in the sky idea of loosely coupling my application to F3.


Loosely coupling your application to its framework essentially means you are going to write a proxy framework. Writing that proxy framework is a lot of work, and if you ever switch to a new framework you'll have to do a lot of work to make the proxy framework support the new framework. Of course, different frameworks use different idioms and patterns, which will make the proxy framework either very complex (if you try to make it fit to everything) or very limited (if you go for the lowest common denominator). Either way you'll have to struggle with that proxy framework.

Is having the ability to change frameworks on a whim worth all this trouble? Like I said, you won't be able to change it on a whim because you'll have to adjust the proxy framework, which might turn out to be more work than adjusting the application code directly.

  • 4
    Your usage of the term "proxy framework" helped clarify the issue for me. – David Kennedy Jan 9 '14 at 3:00
  • 1
    +1 to this answer. There are many times that recoding against the new framework can be much cheaper than the proxy framework creation - which is also speculative. That being said, I think that the whole framework-switching thing is definitely possible and makes sense for frameworks where you have 1) few points of contact to the API and 2) commonality amongst APIs of different frameworks - but I would argue that's definitely not the common case. – J Trana Jan 9 '14 at 5:05

No can do.

You can design in a way that's portable across frameworks. MVC is MVC, and the principles are roughly the same whatever language or platform is used.

The actual code, however, is going to be very framework or language dependent. The only way to abstract yourself from that would be to code based on a intermediate framework. Then you can have the intermediate implementation change (from F3 to .NET ?) without changing the application. Which is a lot of work, assumes non leaky abstractions, and just moves the problem without solving it: you're now tied to your intermediate framework.

On a more positive note: consider expressing some of your tests (BDD style) in a platform independent from your implementation. Those might survive major rewrites.

  • Changing from PHP to .NET is probably not realistic as you pointed out. I'm thinking at a very high level, abstract, possibly lucid. – David Kennedy Jan 9 '14 at 0:56

I once saw Robert C. Martin give a talk where he said something along the lines of "the first decision you make is the hardest one to change later".

So my advice is to try to delay this decision if you're not exactly sure what you want to use yet. Identify pieces that you can define now, and which would easily remain independent of whatever framework you end up using.

  • That's really good advice! – David Kennedy Jan 9 '14 at 3:00

Framework lock-in can be a serious issue, but it helps to look at the problem as one of portability. Portability is not an absolute attribute, but relative to your starting point and where you might possibly want to go. By analogy, then, software is portable only in so far as you have already ported it to other environments.

Most of the development of an application inside a framework tends to be glue code, the stuff that binds the components of your framework together. Configuration files may abstract a certain amount of the glue in some systems but a lot of the fine details have to be done in code.

On the other hand, business rules and processes can be abstracted from the application. The hard part of abstraction is when the rules are implemented directly by the framework; security, accessibility and process sequencing tend to be enforced by your framework and may be the hardest to see.

If you can separate the glue portion of your application from the business rule and business process and business data portion, then you will be able to make some portions of your solution portable.

  • +1. By extracting your business logic in a (web) service, you can let any application consume it, reducing the PHP MVC app to merely a web GUI to your business logic, making it easier to replace as a whole. – CodeCaster Jan 9 '14 at 12:16
  • Designing a web service is akin to designing your own framework. Also, a significant number of your business rules, especially the information engineering part, need to be embodied in the GUI. – BobDalgleish Jan 11 '14 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.