Portable Code for Frameworks?

Question

We have decided to work with the "Insert Framework Here"

We'll most likely update to the next major version of the framework as they come up- however what upper management is worried about, is "What if" the framework roll's over and dies, and code becomes unmaintained? The chances of this happening are very low, but I still have to defend this position.

I have purposely failed to mention the framework to keep all answers to the generic level, as I know framework discussions on here are mostly all opinion.

So, now to the question I am faced with:

What things can we do to keep our code portable to frameworks?

Answer 1

Pick an open source framework? Then if the original maintainer leaves you can still maintain the code.

Answer 2

• Study your alternatives.
• Choose a couple based on:
  • Similarity (template code, architecture, javascript libraries)
  • Diversity (not maintained by the same people, of course)
  • Simplicity (the more simple your frameworks are, the less trouble porting you'll get)
• Study your two alternatives and have migration paths ready (ie, we'll have to rewrite this and that and tweak the database layer here)

That said, if PHP is your language I really, really doubt the Zend Framework will die :-)

Answer 3

Where possible, try to separate out your business logic from an "interaction layer". Basically, this interaction layer wraps calls to the underlying framework, so your application talks to this layer, which is then used to talk to the framework.

By doing this, you may be able to salvage something by just rewriting the interaction layer against a different framework.

Alternatively, you can recommend that you don't have to upgrade frameworks just because there's a new version out, or because the framework is no longer being maintained. Frequently, the decision to update is made by techies, and has no real business case to support it; look at the number of COBOL and VB6 applications that are still running with little to no maintenance.

Answer 4

Abstracting as much as possible can insulate you from framework problems.

I'll give you an example. I've started working with Codeigniter a lot lately. I appreciate some of the stuff the framework does, but I'm not a fan of other aspects of it. One particular thing I don't like is that you pretty much have to use a separate copy of CI for each application you write. If CI comes out with a newer version, I have to go back and upgrade multiple apps.

Because of this, I created a separate directory called "base" in my CI installs, and set up a PHP autoloader to be able to load classes from it. I have things like "Base_controller", "Base_service", "Base_model", etc., and I use this across all my CI installs. These classes extend the normal CI classes, and in turn my applications extend these base classes. For instance, in App number one, rather than write a Controller class that extends Codeigniter's Controller class, I extend my Base_controller, which in turn extends the CI Controller.

This gives me one level of separation between CI and my apps. If CI ever changes, I should be able to manage it by upgrading just my "base" layer. I can also have a lot of base functionality in this layer and only write it once, rather than extending a new install of CI each time.

Abstraction requires careful design, as you don't want to go overboard with it. But it's definitely a useful tool to separate your code from a framework's code.

Answer 5

Some defences could be:

-Adapter pattern

-If it's an open source framework you can develop it yourself, or fork it. The framework not being developed anymore doesn't mean the code dissapears.

-Depending on the framework the models are decoupled from the framework. Eg Zend Framework doesn't specify you use an active record. So your models should be decoupled from the database layer. Since the models are the most difficult part of your application modifying it to an alternative framework is not that difficult if the model is decoupled from the framework (controller, view and db layer).