In every project the discussion comes up over and over again: should we use framework X? or Y? or no framework at all? Even when you limit yourself to the frameworks for web development in the Java space the choices are so plentiful, nobody can know them all. So I need a quick way do identify which frameworks sound promising to me and which I keep for weekend projects.
- Stay away from the new kid on the block. While it might be fun to play with the coolest newest thing, I work on projects that have a life cycle of 10-30 years. I wouldn’t want to support an application using some library that was cool between March and July in 1996. Therefore I try not to put that kind of burden on others.
- Do one thing and do it well. A bad example for this is Hibernate/JPA. It does (or tries to) provide all of the following
- mapping between a relational and an object-oriented model
- caching
- change detection
- caching
- query dsl
It is kind of ok for a framework or library to provide multiple services, if you can decide on each service separately if you want to use it or not. But if it controls to many aspects of your project, the chance that it doesn’t do anything well gets huge. And you won’t be able to exchange it easily, because now you have to replace half a dozen libraries at once.
- Method calls are cool. Annotations are ok. Byte code manipulation is scary. Code generation a reason to run for the hills. In the list only method calls can be abstracted over properly. All the other stuff tends to get in your way. Annotations are kind of harmless, but it is easy to get in situations where you have more annotations than actual code. Byte code manipulation starts to put some serious constraints on what you can do in your code. And code generation additional slows down your build process.
- Keep the fingers of my domain model. The domain model is really the important part of an application. I can change the persistence or the ui of an application, but if I have to rework the domain model, everything changes and I’m essential rewriting the application. Also I need all the flexibility the programming language of choice offers to design the domain model. I don’t want to get restricted by some stupid framework that requires default constructors or getters and setters for all fields.
- Can we handle it? There are many things that sound really awesome, but they require a so different style of coding, that many developers will have a hard time tackling it. And just because I think I can handle it, doesn’t necessarily mean I actually can. So better stay simple and old-fashioned.
| Reference: | What I look for in frameworks from our JCG partner Jens Schauder at the Schauderhaft blog. |
Amen, brother!
Though, I’m not sure about that last point. Mostly, it’s too ambiguous for me to be sure what you mean by it, but if you mean what I think you mean, then it’s a little off the mark. You should be open to new styles, especially ones that help you to make your code more concise and easy to read.
“Stay away from the new kid on the block” – hehe, that’s some great advice!
Unless it’s a toy project, that new kid should stay out of production-grade systems.
I too have been burned by “The New Kid on the Block” too. Another one to avoid is if the framework is a one man show. I remember using a framework that was just one person’s hobby and then they moved on and no one was around to fix bugs or security issues.
one-man-frameworks, I also avoid them, my concern is always, what happens if the dude dies tomorrow, who will maintain that framework …