With all the great programming frameworks out there, its important to be able to understand which,if any, will do your project the most good.
The goal of such an analysis is not to find a winner, but to identify project conditions that cause the framework’s benefit to vary, and determine how beneficial or detrimental each framework is under each condition. In this article I outline the conditions and criteria that should be considered when choosing the right framework for your project (regardless of coding platform). This article is written for developers, architects, and development team leaders.
Conditions to be aware of:
Understand that the same framework that is ideal for one type of project may not be ideal for another type. Here is a list of conditions and anti-conditions that would likely make one framework ideal over another:
multi-developer vs. single developer
internal software vs. web experience
5 screen application vs. 40 screen application
get the project out right vs get the project out right now
There are many other conditions that vary which framework is ideal for your project. It’s important to know what conditions you are under and how each framework adds value under those generic conditions.
Benefits:
Below, I introduce seven criteria to consider when determining the benefits of a framework: Project Re-scope Proposition, Performance and Memory Management, Re-usability, Extendability, and Code Complexity, Testability, and Eco-system.
Project Re-scope Proposition:
Every framework has what I call, a project re-scope proposition. Before any architecture is done, or framework is chosen, we identify the project scope by answering “How should I (or my team) program this application?”. The question(s) that needs to be answered to define identify the development scope is/are the scope proposition.
Choosing a framework will replace the original scope proposition with a new set of questions, our re-scoped proposition . For example, In PureMVC, the questions that allow us to identify project scope are “What are the Commands, Proxies, and Mediators that need to be written? What do the commands need to do? What data should the proxies abstract? What components will the mediators manage? and How will this all be done?” We can add more detailed questions like “How will the application start-up?, What functionality will the facade expose?” And, if we want to get really advanced, we can break the project up into MVC cores. That is just an example of one framework’s project re-scope proposition; every framework re-scopes the project.
Choosing a framework, and software architecting, create a proposes by which the set of questions in a scope proposition are constantly replaced with more questions, questions that are more specific, as constraints are laid out around the solution. In order to accept the constraints of a prospective framework or architecture, you (the developer) should be more comfortable meeting the demands of the scope proposition implied by that decision, than the scope proposition previous to that decision at every step,
Performance and Memory Management:
You should understand the performance and memory management implications of the frameworks you are choosing from. Does the framework have to be used a certain way in order to provide good performance and memory management? Does the framework have any internal memory leaks? Is the framework optimized?
Performance can be less important for RIAs (than games, or video), barring issues that are noticeable by users (slow UI, unresponsiveness). Memory Management may also be less important for internal software than experiences intended for the web.
Re-usability:
A framework is reusable to the extent that it offers out of the box functionality that you would have had to write if you hadn’t chosen that framework (PureMVCs startup logic comes to mind). A framework is re-usability friendly to the extent the framework encourages you to write reusable code. For example, if a framework decouples the view from any other part of the program, and puts no constraints on view components, then you can write reusable view components.
Re-usability (like complexity) is measurable. An application’s re-usability is the amount of time that will be saved for all future projects by leveraging code written for that application.
Extendability
A framework is extendable to the extent the framework follows the open-closed principle (http://en.wikipedia.org/wiki/Open/closed_principle ) for classes that represent entities which vary in behavior between projects.
Code Complexity:
A good framework encourages low class complexity.
Simple classes are simple to write, test, debug, and modify. Complex classes are not. A simple class will require the developer to have less information about the rest of the program than a complex class will. Based on the definition of a simple versus a more complex class, we can define a project’s code complexity.
We define the complexity for a class as the amount of functions and properties it can access.
We define the measurement of the code complexity for an entire program as the sum of the the complexities of the classes.(Please note, these are my own definitions.)
The complexity of a code base is predicated by the amount of classes that are imported and the amount of members each class exposes to the importing class.
This concept re-enforces the importance of defining access for your members (public/private/protected/ [internal or friend])
Testability
A good framework encourages classes written on top to be easily testable. Here is a great article that describes how to write code that is more easily testable: http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-decided-to.html
Eco-System
The Eco-System describes the real world factors outside of the framework code that can add value to the experience of working with a particular framework. Does the framework have a forum or email list? Is/are the author(s) accessible? Is there a large user base that will help you with your questions? Are there other libraries or tools (i.e. PureMVC Console) developed for that particular framework that add value?
Conclusion
I hope this article has established guidelines for an analysis of code frameworks. The decision is not simple, as this article has already touched on two dimensions (conditions versus criteria) with at least 4 and 7 elements in each dimension, respectively.
In my next article I will attempt to deal with concrete frameworks and provide some analysis using the guidelines submitted here.