How Do You Decide Which Framework to Use?

GPolancic asks: "Software frameworks are increasingly popular software reuse technique, because they provide infrastructure functionalities to an application, or a layer of an application and therefore reduce the work of a software developer. Numerous complementary (for example: Struts and Hibernate) and competitive (for example: JSF vs. Struts or JSF vs. ASP.Net) software frameworks are available as both proprietary and open source software. A major precondition for the success of a software framework is their acceptance, which is related to market share or community size. On the other side, application developers need to review and select the best available software framework for their needs. Which factors do you evaluate before you decide to use a specific software framework?" "Our presumption is that software developers mostly evaluate following software framework characteristics based on:

1. perceived ease of use (e.g. easy to learn, easy to adapt)
2. perceived usability (e.g. improving developer performances, reducing work, faster development),
3. perceived sustainability (e.g. perceived long term support, supporting standards, clear project directions) and
4. perceived fit to specific developer requirements (e.g. suited language, suited functions, suited architecture).

What are your criteria? Do you support the factors listed above? I am not asking for a preference on a specific software framework, but rather an explanation on the non-trivial task of framework selection, which might be very usable for both frameworks developers and framework users."

Comments

Re:Difficult to answer

[Tony Hoyle]

More to the point, the design will answer the question for you (as it does for the 'what programming language' question).

You design the application *then* you start making technical decisions about implementation - not the other way around.. there's already too much crap produced by people who *must* use the latest wizzy 'framework' and then design an app to use it regardless of the functional requirements.

Re:Simplicity is key

[Serveert]

HQL has major limitations but you can rip out into native SQL using createSQLQuery() I believe. Map it into a hibernate class and you're golden.

When selecting aggregates, JDBC works well. But Hibernate is pretty amazing if you are aware of its limitations. 90% of my code uses hibernate, 10% uses jdbc.

And the code that uses hibernate is pretty neat, it cuts down dev time significantly. I use hibernate tools in eclipse, point it to the DB and it generates all the classes, parsing foreign keys, making the associations.

Don't get me wrong, I like to be unique and cynical, against the grain if you will, but hibernate, despite the jerk off creator of it, is amazing and useful.

What is a framework?

[SickLittleMonkey]

A framework ...

"... dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on your application. The framework captures the design decisions that are common to its application domain."

Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software.
Quoted from Tapestry in Action by Howard Lewis Ship.

Howard continues: "Frameworks are very useful; instead of your having to start with a clean slate, the design is partially filled in and the path to follow is clear. Many design decisions are already made for you, decisions that leverage the combined experience of the frameworks' authors and users."

And that's why when weighing up JSF or Struts, I chose ... Tapestry!