Wiki Home

Frameworks Love Em Or Leave Em


Namespace: WIN_COM_API

Thanks to Beth Massi for this article

Frameworks, Love ‘em or Leave ‘em.
A Guide to Evaluating a Programming Framework

By Beth Massi
July 2000

In this article I take a look at the issues involved when researching a programming framework. You can use this article as a guide to help you ask the right questions when looking at frameworks. It contains the guidelines you need to pick the right framework for your business. All of the questions here apply to any type of framework be it desktop or distributed. This isn’t a “which framework is best” article, since there are different frameworks for different things and what’s best for one person may not be best for you. Rather, I try to get you thinking about what is important and what you need to decide in order for you to pick the framework that is best for you.

To really be convinced a framework is right for you, you'd have to build an application. Of course, if you have time to create eleven different prototypes with eleven different frameworks you probably have enough time to write your own! Installing and figuring out the basics of how to design the simplest thing may take you more time than you have. Face it, if you had time you probably wouldn't need somebody else's framework. That's why I've come up with these questions you need to ask yourself before jumping head first into a framework.

Ask Yourself …

What are your primary goals of using a framework?

What is the learning curve?

Does the framework do too much or too little?

Who makes the framework?

Is price important to you?

Pros and Cons

When (or if) you finally pick a framework and implement it as a company/application standard, you are basically “stuck” with it. Very often you develop a love/hate relationship with it (I had an ex like that ). A good framework, however, will let you extend it and do what you want it to do in a fairly easy way. However, if you make the wrong choice, the framework can become a hindrance instead of a help.And even if your choice is good, it is up to you to abide by the framework’s programming guidelines otherwise you can end up programming around the framework instead of in it.A framework may dictate how an application looks or behaves and you may not like it. Make sure that if you don’t like it, you can easily change it and wont be penalized by losing features. Some frameworks out there are not very forgiving.

A framework can get you up and running in less time and better than if you did it yourself. This is usually the biggest reason people use frameworks. Frameworks handle the complexities of the application allowing you to concentrate on the business goals. This means you can spend a lot more time and effort on what’s important, the business rules and processes. A good framework will also separate the application layer from the business layer in separate classes or files. This way, upgrades to the framework can be done without affecting your business code.

Working with a good framework can also be a great learning experience. You get insight into how another expert developer solves a problem. Prototyping with several frameworks or developing with a single framework can give you exposure to and a basis for creating your own framework.

Distributed Application Framework Considerations

When selecting your DNA framework in addition to the questions above there are a few specific questions you should ask yourself.

  1. Do I need a framework for all tiers of the application or just the middle tier?
  2. Do I need a middle tier to support thick (GUI) and thin (Browser/HTML) clients?
  3. How many users do I anticipate this application to have? (Double your answer)
  4. How easy (or hard) will this application be able to scale?
  5. How easy (or hard) will deployment and upgrades be?

I have found that the more a DNA framework tries to do, the harder it is to maintain yourself. Frameworks that aim to do a specific job tend to be easier to learn and extend. In the past I’ve personally preferred to develop my own frameworks. However, with the need to develop business internet applications so quickly, I’ve found one that fits my needs. It is purely middle-tier which allows me to have graphic designers and presentation programmers working on the client side, the developers concentrating on their business logic and processes using the framework, and the DBA’s maintaining the databases. What makes the framework “work” for me is that I can separate the complexities of data marshalling, connection handling, create/retrieve/update/delete (CRUD) functionality, and transactioning, from my business objects, rules and processes.

Here's what I mean:

In the diagram above the blue objects are the pieces of my application that is under a framework. Notice that the framework does not dictate the front-end user interface or back-end database, it is only a middle-tier framework. I have the flexibility to determine which database and what kind of user interface I want to develop. The framework handles the data marshaling to and from the database as well as many other details like connections and transactions. The framework is also written in an Object Oriented Language which allows my business specific classes to easily inherit from the framework layer.

Conclusion

It may not be in the cards for you to adopt a framework. However, there are a lot of good reasons to do so. It's kind of like getting married. Choose the best one and stick with it otherwise go through a painful separation and start over again.


Category Frameworks
( Topic last updated: 2002.09.09 11:35:56 PM )