Alexander has posted 1 posts at DZone. You can read more from them at their website. View Full User Profile

The "Frameworks" Trap: Common Challenges

02.16.2008
| 7016 views |
  • submit to reddit

I would like to talk to you about Java frameworks. Do you think frameworks are good or bad… or something else? Please notice that I specifically said JAVA frameworks. This is because Java, more than any other language, has a wide variety of frameworks readily available. In fact, the large number of frameworks for Java is one of the problems I want to talk about.

Here are a few areas where problems can occur with frameworks:

  • Picking the right tool for the job
  • Understanding the inner workings
  • Too much variety to choose from

 

Picking the right tool for the job

I think this may be the biggest and the most fundamental problem most developers have with frameworks. Prior to choosing a particular framework, you need a clear understanding of why you might choose it and whether or not it really fits your needs. I very often encounter projects where poor choices have been made in framework selection, and all kinds of problems result.

Take Hibernate, for example, a great framework that is NOT always the right tool for the job! I often find Hibernate used for programs that may require as few as 10 different SQL queries. Instead of a simple JDBC solution, these projects become bloated with an additional dependence on Hibernate and a large amount of unnecessary code. I've also seen problems with Hibernate in situations where an application must be built to use an existing database that has a very complex and inflexible schema. Although Hibernate generally simplifies object-relational data persistence, in these cases it can be surprisingly difficult to get the best out of both Hibernate and the existing database..

A similar situation sometimes occurs with Application Servers. Although they aren't frameworks, they still provide a wonderful opportunity to choose the wrong tool for the job. Very often I have seen expensive, full-featured application servers deployed just to power a simple WEB application, when in reality a simple Servlet Container would suffice. It's quite like using an ORM framework when a few SQL calls will do the trick.

The framework (and app server) you choose should correspond appropriately to your goals and requirements. Otherwise, you may end up with more disadvantages than advantages.

Understanding the inner workings

Misunderstanding the inner workings of a framework can result in unpredictable results. Often, this translates into terrible performance. Let's take Hibernate again (although I honestly don't mean to pick on Hibernate!) If you don't understand how it works, then it is easy to write code that creates an enormous amount of SQL queries. You end up scratching your head and wondering why your application is so slow.

The moral is: if you decide to use a framework, then you need to have at least a basic understanding of how it works.

Too much variety to choose from

Ironically, because there are now so many frameworks, it can be really hard to choose exactly which one to use. There may be several reasonable options available to solve your problem. For example, how many dependency injection frameworks are there now? Should you choose Spring, Guice, something else? It's really not that easy to know which one will work best, and you can spin wheels for a long time trying to decide. The bountiful range of options actually becomes a problem (although it is certainly better than having no options.)

Be wary when you read the feature list of a framework. It may seem like it is a solution to your problem, but you could be disappointed once you roll your sleeves up and try to work with it. Some framework authors have been known to suggest that their frameworks can do nearly everything, while the reality is often more limited. There are also sometimes novice developers who don't even want to understand how to solve a specific problem. They just want to take framework and hope it will do everything for them. The results, of course, are exactly what you would expect.

Conclusion

Before choosing a framework, take the time to study it. Try to understand how it works and whether it is really suitable for your tasks. The wrong framework can complicate your task and put your whole project at risk. For some very specific tasks, you may not need a framework at all. Just write the basic code you need by yourself. Keep in mind that once you start making use of frameworks, it may become difficult to give them up because of dependencies you introduce into your code.

P.S. I really don't mean to say anything negative about Hibernate. I like Hibernate and mention it only as an example.

Published at DZone with permission of its author, Alexander Beloturkin.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Steven Baker replied on Tue, 2008/02/19 - 10:57pm

Although your pointing out some traps, and yes, alot of projects end up bloated due to an incorrect choice of framework.

However, you have to consider that even if the project begins as a small app that could be created as standard JDBC and a servlet, the initial setup has to be setup to be scalable.

Using a framework such as hibernate, JSF etc, might at first seem like overkill, but can serve you well in the future if the project grows rapidly.

Though ofcourse, the project leader would need to work out if this is expected to occur or not... 

Rainer Eschen replied on Wed, 2008/02/20 - 6:00pm

You're right. You've to have a deeper look at what the framework does, but I don't think there's time left to study this deeply. And thinking about frameworks in general I don't like the fact that I have to have a look at source code, considering todays OpenSource documentation quality.

But, for me the integration aspects are the most important ones. The functionality of a framework can be taken for granted in most cases, but integration is always a challenge. Maybe it's one of the sideeffects that there are so many alternatives. I wish we could have commonly accepted standards in the different layers so that the developers of such frameworks think about doing a good integration job. Today a lot of integration is done by framework users, reinventing the wheel on a daily basis.

The Spring guys are a good example for what can be reached. Hibernate and Spring, e.g., are perfectly integrated. You even get a polished exception hierarchy.

Roberto justme replied on Thu, 2008/03/20 - 11:06am

Anybody knows a blog or site where has been made a comparison among many java frameworks in order to have an idea about plus and minus ?

Thanks

 

Rob 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.