1

I have some questions related to framework dependency. Generally best coding practice says that don't clutter your namespace with framework specific code. For e.g. in case of spring all the dependency should be maintain in config file and there is no spring specific code in your application code (and that is one of the reason to preferring spring config xml file over spring annotation). Same way in case of puremvc its always preferable to don't mix puremvc code in mxml, so your view can work with any framework. But my question is

  1. If we remove spring or puremvc from your code without replacing any other framework then you are end up in few beans (in case of spring) or some truly reusable views (in case of puremvc). But gluing beans or view requires large amount of coding effort, according to me its indirect dependency of framework without using framework specific api.

  2. If we replace spring with other DI framework like pico container then also it requires substantial amount or rework. Which again leads to indirect dependency on framework.

So, why its bad to clutter your our application namespace with framework specific api ? Just we can code for framework specific api (if it really ease out our coding effort substantially).

According to me, just not mixing application namespace with framework specific api doesn't makes your application portable for other framework. Think if you want to move your existing well designed struts application with spring mvc and how much efforts it requires to do so.

Expecting view from other readers.

Silent Warrior
  • 5,069
  • 8
  • 41
  • 52

2 Answers2

2

I think its a basic principal of software design to keep your concerns separated. Just as you don't want view code in the model layer in MVC, you don't want container specific code in your application code.

You are correct that in many situations one needs to write code for their tools. You might write some hibernate specific code for example, if you need a custom type, or some spring specific code if you need a custom application context. There is nothing wrong with that. The key is to keep it separate from the other functional slices of your application.

This does not guarantee "instant" portability. What it does promote is the ability to port the code elsewhere "easily". "Easily" in this context does not mean no work. Rather it means you won't have to start ripping out the Spring specific stuff because you've decided to move to Pico. In other words, your core business functionality remains intact, and all you have to do is port the configuration or container specific dependencies when you decide to move.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
1

As with all abstractions in software development you're simply moving 'the problem' around when you are using a framework. The framework takes care of certain things so the other parts of your application don't need to know how to do that. E.g. if you use dependency injection the classes that get injected don't need to know how to create their dependencies, it's handled by the dependency injection framework.

But this only means that the knowledge/responsibility is moved. It is never, ever, re-moved. So yes, of course your code implicitly depends on that framework. But, if you move the framework related code to one location, maybe even introducing some interfaces to wrap it, you can sometimes make it so that the rest of your code is dependent on a interface, class or framework, instead of the specific framework.

E.g. I introduced an IIocContainer interface in my code, with only Resolve methods. An object implementing this interface holds the knowledge of how to call the specific Ioc/DI framework. But this knowledge is only in this one object. The rest of my application (where needed) only ever knows about the IIocContainer interface and thus doesn't depend on a specific framework. If I change framework I only need to change the references and configuration (which might be in XML and not influence code at all) and use a different object that implements IIocContainer for this container.

When you're talking about frameworks that directly influence the structure/architecture of your code (e.g. by base classes, naming conventions, etc.) this means it becomes much harder to abstract away the specific framework. You could, but what you'd basically be doing is writing your own framework around another framework. It wouldn't be worth wile, because in the end if you're going to switch structural frameworks it's always going to be a lot of work, either by directly rewriting for that framework or by abstracting the framework away.

I think you can put it simply as: if you're using a framework to move the problem of 'a lot of structural plumbing to do' into that framework (let the framework handle the plumbing for you) and you switch framework you're going to get the 'a lot of structural plumbing to do' problem right back. :-)