|
Written by Fred Hirsch
|
|
Wednesday, 07 July 2004 |
|
Do you really need a framework when creating a new web application? Do they bring too much overhead to the table, and are they really as useful for rapid application development? I'll discuss these questions and hopefully dispel the myths and explain the facts regarding the usefulness of frameworks.
What is a framework? Some developers might argue that presentation systems like PHPNuke constitute a framework, but in essence, this is an actual web application (specifically a content management system) and is not a framework. A framework is a core set of components that usually comprise a typical Model-View-Controller paradigm. Most well designed frameworks actually have no direct application use out of the box. By this, I mean that installing a framework should not give you a working website. A framework really needs to provide three core components for the application backbone. I will explain these components within the domain of web development, and not windows application development as they may have originated from: - The Model - Most applications have data which is stored and needs to be retrieved and modified within the lifecycle of the system. The model provides a common way for the entire application to manage this information. In a web framework this typically consists of a database abstraction layer that allows multiple database servers to be used by a single framework, and a set of data access objects that understand how to extract and communicate information to other parts of the system. It is easy to over complicate the model into many subsections and apply various complex design patterns to the model, but these abstractions basically boil down to the same ideas... get the data, use it and store it back after its been played with. In some contexts, the model also should include the core business logic of the application. Some frameworks like to make this a separate layer of the model, and that is generally recommended. We'll discuss business logic and what that means a little later.
- The View - Its all well and good to be able to play around with all this information, but it has little usefulness for the end-user of the application without being able to see the data. The view provides this interface, and in web applications this is often managed using HTML templates to build sites through a common markup methodology. The template can then be parsed and the model data can be represented based on the markup. Separating the data and inner workings from the display allows the display to change without the requirement of managing the backend code and vice-versa.
- The Controller - The controller is needed to dispatch user requests to the model and then present the view back to the user. Separation of the controller from the view and sometimes the domain is often considered a cloudy aspect of web application design. Many frameworks do not make a clear distinction and often bundle the view with the controller. However, its important to manage the controller separately.
So, what does all this really mean? Essentially, the framework is all the core services that you need to accept requests from users, extract and manage data for them and then present the results of that request back to the web browser. Frameworks also often provide authentication functionality, session management and other core components used by many types of applications. Do I Really Need a Framework? Many of the most popular web applications don't even use a formal framework, why should you consider one? As a developer, you may have worked with modifying these same applications. Each customized code element is painstakingly added to each separate code module to provide the common look and feel for each application screen. Often you may need to change "code" when you are really only making layout modifications. So, what happens when the original developer of the application releases a new version of their code that has many new features you need? Most likely, you have to go back through all those files and make those revisions again. This really puts the "pain" in painstaking, doesn't it? Frameworks don't have to be complicated, and can be very simple. On the simplest level, its only needed to keep the view completely separate from the model. Some might not even consider this a framework, but if you can use it to model your application, it really is one. This means utilizing templated display of some sort on the frontend and a common method of abstract data retrieval on the backend. There are many levels of abstraction that can be provided by a framework and some are much more robust than others. Keep in mind that as the complexity of the framework increases, so does its performance requirement (for the most part). A lightweight framework can easily be developed for personal use, or a heavier version could be expanded upon or used from a third party. In future articles, I plan on reviewing various framework products that are available and why you might choose a specific one over others. |
|
Last Updated ( 2007-05-30 20:18:58 )
|
