Defining a framework - Blog - Open Source - - php, photography and private stuff

Defining a framework

I attended the talk Framework? No thank you, I will use my own!, this week at IPC 2009 SE. The idea of the session was to get a discussion running about if you should use one of the many existing OSS PHP frameworks out there, or if you go better with building one on your own. Driven by the speakers Lars Jankowfsky and Thorsten Rinne, the result was quite obvious for many reasons already beforehand: Use an OSS framework!

While I fully agree with this result, I stated a somewhat controversial thesis right at the beginning of that talk, mainly to get the discussion running:

If your team is small and you have few experiences in software development, be sure to go completely for an OSS framework. But if you have a bigger and more experienced team, it might be wise to go for your own framework.

I was buthered by the audience, as expected, for various reasons. To not bring the session into the direction of this blog post, I did not argue further here. Therefore I'd like to resume my argumentation now and look at what a framework actually is and what the common understanding seems to be.

Official definition

There is no official definition for the term framework, like an ISO or any other standard. However, there are some common understandings of a software framework. As Wikipedia states:

A software framework is a re-usable design for a software system (or subsystem). A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an API.

Following this definition, the crucial point of a framework is the (well-defined) re-usable design, the basic principles you want to build your software on. Furthermore, a framwork might include support programs (scaffolding?), code libraries and glue code.

The Wikipedia page about software framework furthermore states that

Frameworks are similar to software libraries in that they are reusable abstractions of code wrapped in a well-defined API. Unlike libraries, however, the overall program's flow of control is not dictated by the caller, but by the framework.

The crucial point here is the difference between a code library and a framework: The framework dictates how things are to be done, while the software library only provides re-usable components without dictating their actual usage.

Framework understanding

Both definitions reflect my personal understanding of a framework quite well: The framework defines how common things are to be done in software projects based on it. The framework defines the basic code structure, common patterns to be applied and the overall environment of the application.

In terms of PHP this usually means, a framework defines that the MVC pattern is to be used and which base implementation of it (ZF? ezc? custom?). Further basic architecture patterns are commonly defined: A data access layer, template system, hopefully a test framework and maybe others.

Very importantly, a framework contains essential application development guideline like a definition of how new modules must be designed, a common directory structure, class naming scheme, coding guidelines, test guidelines and more. The framework might contain tools to setup the essential structure of a new project or a module in a project (scaffolding).

In addition a framework should contain software components to perform essential tasks in the affected type of application, like accessing configuration and validating user data.

A framework can also contain further software components to solve certain tasks. A component to send email is commonly useful, since this is a very common task in web applications.

However, a framework should usually not contain much more, like components for special tasks (e.g. generating images). Such tasks are very application dependant. There is no universal solution for them and trying to provide a solution that must be used mandatory is not in the sense of software development. Remember: Choose the right tool for the task!

In this sense, a framework is not what I feel the common PHP developer has in mind. It is not a large collection of software components, chosen once and set in stone. It contains not the Flickr service access class and not the WebDAV server component. The framework is only the common structure of your applications, containing the most essential software components and glueing them together. Its the way you do things, not the tool you choose for a specific task.

A lot of the frameworks in the PHP OSS world are actually code libraries. Some of them (like ZF), provide a real framework and a large code library in addition to that. Zend Framework provides an MVC implementation, scaffolding tools and infrastructure classes. But also a lot of library classes.

Creating your own framework

Saying that it makes sense to create your own framework does not imply that you should re-invent the wheel. There is definitely no need to code a whole framework from scratch. Creating a framework does mean to write the code.

However, it makes sense to consider, which parts of an OSS framework suite your needs and which not. For example, you should evaluate if you want to use one of the existing MVC implementations. Is the MVC under consideration fully satisfying your needs? Does it fit your architectural requirements? Would it make sense to extend it in some way, if this is not the case? What about the infrastructure classes? Is the database layer made up the way you prefer it?

These and many more questions need to be discussed before you decide to follow one framework. Exchanging the framework later (especially the MVC) is a hard and time consuming challenge.

If you are not satisfied with the design of any part of the framework and you cannot solve your concerns using inheritance or other appropriate mechanisms: Do not use it! Instead, look for an alternative on the web and see if you can integrate that with the other framework components. If you don't find a satisfying alternative, maybe consider to write this special part yourself.

This way you can create your own, custom framework, without re-inventing the wheel.

When it comes to the code library part of your framework, don't tie the ropes too strong. There are many good PHP component libraries out there. If you face a certain challenge, pick a component that solves this challenge. No matter if it is part of your chosen framework or part of another one (or another code library). It is quite fine to use ZF as the basis and use components from eZ Components in individual projects, for example. It is also fine to mix different frameworks / libraries in your personal framework.

Choosing the parts of your framework

During the discussion at IPC, many criteria to select a fitting framework were already mentioned. To complete this article, I will try to summarize the most important ones. Giving a deeper insight is not possible here, but should be left for a later article.

For choosing a framework (after the definitions above), it is most important that the chosen approach fully satisfies your architectural requirements. If this is not the case, chances are good that you get stuck, once you start development. Check the overall concept and the extensibility. Breaking out of a framework is not the goal, but sometimes inevitable. Check, if it is possible, if you once reach the point where you need it.

This also applies to the basic infrastructure components of your framework, like template, data access layer and configuration component. If one of them does not suite your architectural requirements, don't take it and look for an alternative.

Furthermore, the open source community driving the project you choose parts of your framework from is important. Is there a vital community or just one man driving it? The latter case is obviously not good. Is there a company behind the library, so you can potentially get professional support? Are the maintainers of the different components fluctuating or is the community stable? A good starting point for such evaluation is the version control system and the issue tracker.

How stable is the project you want to pick components from? Check the number of open bugs and more importantly the closed ones. How fast and accurate does the project respond to bugs? Do people contribute patches? How does the project handle regressions? Are there mechanisms in place to avoid them? Most importantly: Tests? Is the test coverage good? Do spot checks to get an insight of the test quality.

Last but not least: How is the documentation? Is every bit of the API documented? Is the code self-documenting? Do tutorials exist? Can the tests deal as additional documentation?

If you liked this blog post or learned something, please consider using flattr to contribute back: .



Add new comment

Fields with bold names are mandatory.