Building PHP Applications with Symfony, CakePHP, and Zend Framework E-Book

Bartosz Porebski

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 705

Veröffentlichungsjahr: 2011

Beschreibung

The first detailed, unbiased comparison of the three leading PHPframeworks Web developers have been eager for an impartial comparison ofleading PHP frameworks so they can make educated decisions aboutthe most effective tool for their needs. This guide uses Symfony,CakePHP, and Zend Framework to solve key problems, providing sourcecode examples and comparisons for each. It explains the approachand reviews the similarities and differences in the threeframeworks, providing reliable information on which to base yourdecisions. * Symfony, CakePHP, and Zend Framework are considered the leadingPHP frameworks; developers need an unbiased comparison to choosewhich one works best for their individual situations * This guide uses each framework to solve the same problems,illustrating the solutions with source code examples and workingapplications * Covers wide range of topics, from installation andconfiguration to most advanced features like AJAX, web services andautomated testing. * Includes an appendix of new PHP frameworks, includingCodeIgniter, Lithium, and Agavi * Bestselling PHP author Elizabeth Naramore serves as technicaleditor Comparison of PHP Web Frameworks provides the impartial,side-by-side comparison that developers have been looking for.

Leseprobe

Table of Contents

Title Page

Copyright

Dedication

Credits

About the Authors

Acknowledgments

Introduction

Who Should Read This Book?

Comparative Approach

Structure of This Book

Source Code

Conventions

Contact Us

Errata

p2p.wrox.com

Chapter 1: Introducing Symfony, CakePHP, and Zend Framework

What are Web Application Frameworks and How are They Used?

Open Source PHP Web Frameworks

Design Patterns in Web Frameworks

Chapter 2: Getting Started

Requirements

Installation

Configuration

Hello World!

Structure

IDE Support

Chapter 3: Working with Databases

Object-Relational Mapping

Database Configuration

Communication with a Database

Chapter 4: Your First Application in the Three Frameworks

Design

Symfony

CakePHP

Zend Framework

Chapter 5: Forms

Field Validation

Customizing Forms

Using Captcha as Spam Protection

Chapter 6: Mailing

Creating Mailing Applications

SwiftMailer

CakePHP's Mailing Component

Zend Mailer

PHPMailer

Chapter 7: Searching

Problem

Solutions

Chapter 8: Security

Setting Secure Connections

Securing a Profile Form Against XSS and Injection Attacks

CSRF

Chapter 9: Templates

Creating a Simple Image Gallery by Using Helpers and Lightbox

Using Template Engines within Web Frameworks

Overview of Other Add-on Template Engines

Chapter 10: AJAX

Introducing AJAX

Autocomplete

Dynamic Popup Windows

AJAX User Chat

Chapter 11: Making Plug-ins

Symfony

CakePHP

Zend Framework

Chapter 12: Web Services

Restful News Reading

Providing Soap Web Services in E-Commerce Applications

Chapter 13: Back End

Symfony

CakePHP

Zend Framework

Feature Summary

Chapter 14: Internationalization

Internationalization Defined

Symfony

CakePHP

Zend Framework

Chapter 15: Testing

Introducing Testing

Black-Box Registration Form Testing Using Functional Tests

CMS Tests Automation Using Selenium

Mailing Unit Testing

Chapter 16: User Management

Basic User Management

Identifying Users Using LDAP Implementation

Chapter 17: Performance

Using JMeter for Stress, Load, and Performance Tests

Benchmarking

Development Speed

Chapter 18: Summary

Features

And the Winner Is…

Appendix A: Web Resources

General

Symfony

CakePHP

Zend Framework

Design Patterns

ORM

Databases

LDAP

Searching

Testing

Security

PDF

Web Services

Mailing

Templates

IDE

Javascript

AJAX

CMS

CodeIgniter

Lithium

Agavi

Appendix B: CodeIgniter, Lithium, and Agavi with Code Examples

CodeIgniter

Lithium

Agavi

Glossary of Acronyms and Technical Terms

Index

Building PHP Applications with Symfony™, CakePHP, and Zend® Framework

Published by

Wiley Publishing, Inc.

10475 Crosspoint Boulevard

Indianapolis, IN 46256

www.wiley.com

Copyright ©2011 by , Karol Przystalski, and Leszek Nowak

Published by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN: 978-0-470-88734-9

ISBN: 978-1-118-06792-5 (ebk)

ISBN: 978-1-118-06791-8 (ebk)

ISBN: 978-1-118-06790-1 (ebk)

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone]. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Library of Congress Control Number: 2010942182

Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Symfony is a trademark of Fabien Potencier. Zend is a registered trademark of Zend Technologies, Ltd. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

For my beloved Olcia, who keeps inspiring me to achieve goals I could have never dreamed of. The way you are able to solve with your pure wisdom all the analyti-cally unsolvable problems, your dedication, and your sense of humor still amaze me every day. And the sweet cakes (no PHP added) you baked for me while I was writ-ing this book were simply delicious. I would also like to thank my parents for their continuing faith and support.

—

For Agata.

—Karol Przystalski

I dedicate this book to my parents, for their constant love and support. They made this book possible. I also warn any readers of this book not to try and run the code examples backward! It may cause hellspawns to appear out of thin air.

—Leszek Nowak

Credits

Executive Editor

Carol Long

Project Editor

Tom Dinse

Technical Editor

Wim Mostrey

Production Editor

Daniel Scribner

Copy Editor

Nancy Sixsmith

Editorial Director

Robyn B. Siesky

Editorial Manager

Mary Beth Wakefield

Freelancer Editorial Manager

Rosemarie Graham

Associate Director of Marketing

Ashley Zurcher

Production Manager

Tim Tate

Vice President and Executive Group Publisher

Richard Swadley

Vice President and Executive Publisher

Barry Pruett

Associate Publisher

Jim Minatel

Project Coordinator, Cover

Katherine Crocker

Proofreader

Word One

Indexer

Robert Swanson

Cover Designer

Michael E. Trent

Cover Image

© Xiaoke Ma/istockphoto.com

About the Authors

is a video games, web applications, and C++ software developer. He works as Brain-Computer Interface researcher and lecturer at Jagiellonian University in Kraków.

KAROL PRZYSTALSKI is a Software Quality Engineer at Sabre Holdings and a PhD student at Jagiellonian University in Kraków. He has worked with Symfony since its earliest versions and wrote a book on the Symfony framework.

LESZEK NOWAK has years of experience in web development and graphics design with such frameworks as Django, CakePHP and CodeIgniter. He also works with 3D modelling, animation, image recognition, and artificial intelligence development. He says, “Science is fun, if used in games.”

Acknowledgments

NO BOOK IS THE SOLE effort of its authors, especially such a long book. It took long months and countless cups of coffee to keep us awake and writing and programming the code examples. We could not have made it through this if not for the help and patience of many kind souls.

First of all, we want to say a big THANK YOU! to the Wiley/Wrox team we had the pleasure of working with. Carol Long showed great patience and motivated us when we were down. Tom Dinse and Nancy Sixsmith worked hard to get our English right. Wim Mostrey made sure that all technical matters are 100% correct. Ashley Zurcher helped to successfully deliver the book to the market, and Helen Russo took care of our legal matters. It was really fun to work with you folks!

We also want to thank our superiors on the faculty of Physics, Astronomy, and Applied Computer Science of Jagiellonian University in Kraków: dr hab. Ewa Grabska, prof. dr hab. Maciej Ogorzałek, prof. dr hab. Maciej A. Nowak, and dr hab. Paweł Wgrzyn, who were really supportive and did their best not to swamp us with additional jobs while we were busy writing.

Finally, our thanks go also to all the developers who dedicated their precious time to write good documentation and share their knowledge.

Introduction

Honest differences are often a healthy sign of progress.

—Mahatma Gandhi

For a long time, PHP was disregarded as a language not serious enough for rich web applications. Everyone knew it was popular and perhaps good for small one-shot projects, but all the praise was reserved for the aristocratic elite of frameworks such as Spring, Ruby on Rails, or Django. Only recently has the situation changed, and it changed dramatically. In 2007, it became clear that PHP has not just one, but three major web application frameworks extending capabilities of this language: Symfony, CakePHP, and Zend Framework. The pace of development was fast and steady. Object-oriented source code written in PHP5 was elegant and maintainable. More and more new projects began using them, and their successful completion made the PHP frameworks even more popular.

Nowadays, the popularity of PHP web development frameworks surpasses all others (the evidence is inside this book), and they have become a leading force in the industry. The aim of this book is to gather as much knowledge about this dynamic force as possible and portray all the features these frameworks provide to our fellow programmers.

Who Should Read This Book?

If you are actually looking for a vampire novel, put this book back on the shelf. Immediately. If you are a hard-core Assembler programmer who needs no web interfaces at all, you might not be interested, either. However, if you are involved in some kind of web development, you will probably find this book useful. It is thick and heavy enough to cover a wide range of topics and provide various perspectives for all kinds of readers:

Professional PHP web application developers were the first people we thought of when we started writing this book, perhaps because we are PHP programmers, too. Frameworks offer multiple advanced features that can make our lives easier and more exciting. That's why we wanted to dig deeper and try out whole potentials of different frameworks and thoroughly compare them for your pleasure and convenience.Experts in Ruby on Rails, Django, TurboGears, Struts, ASP.NET, or other non-PHP frameworks who want to take a closer look at PHP. Instead of buying separate books for each framework or choosing one more or less at random, they can benefit from comparing examples hands-on. They can experience the differences between the frameworks, which sometimes are really subtle, and perhaps switch to PHP one day.Students and PHP beginners should not be afraid of the complexity of some more advanced topics. This book is a tutorial, but it is also much more! We have put a lot of effort into making it accessible. The first part of this book, “The Basics,” covers everything to get the whole thing (or even three things) running. The second part, “Common Tasks,” is more than adequate to serve the needs of most academic courses or a plan of individual education. The rest of the book will be very useful if you decide to continue your romance with any one of the frameworks.Project managers, analysts or system administrators who often decide on which technology to choose or who need a deeper understanding of existing computer systems and applications. We have prepared a whole part (Part 4, “Comparison”) that is focused on comparing the three frameworks and discussing their capabilities.Advanced non-web programmers, such as C++ application engineers or database experts who want to explore the vast world of web development, will find that this book is also a good starting point for them. They might be delighted with the object-oriented approach of PHP5, the rapid building process made possible with the frameworks, and all the advanced features provided by them. Meanwhile, the comparative approach provides a broad view of web-specific problems, and the tutorial side of the book prevents being stuck simply with more trivial tasks.

Comparative Approach

There are many great tutorials and books on each of the frameworks covered in this book. What makes this book unique is the comparative approach we've adopted. We wanted to do more than just present three advanced technologies—we wanted to point out their advantages and disadvantages by comparing how each solves certain problems. This gives you a very practical tutorial-like experience and a solid base for more advanced discussion. It allows you to formulate your own views on PHP web frameworks and their suitability for your needs.

Flame wars are a hallmark of all discussions about web frameworks. Everyone has a favorite and tries to promote it against all others. The problem is that all web frameworks are used for the same purpose, but have different internal structures. Knowing one of them is generally enough to produce web applications, so there are few people interested in mastering multiple tools of this kind. This makes comparisons difficult. No wonder many discussions are based on stereotypes, personal opinions, and unverified data.

In this situation, many unanswered questions arise: Which framework is best suited for my particular purpose? Which one is the quickest to learn? Which one produces applications the fastest? Which one has the richest features? Which one will I like best? Is there one that surpasses all the others? We have asked these questions ourselves and found no reliable answers. However, because these questions are often asked by other developers, we decided to do our best to find the solution and then share it in this book. The results were often really surprising.

Structure of This Book

The main principle of this book is to show how to do some tasks in each framework (in parallel wherever possible). To accomplish this, each example is repeated for each framework. Sometimes the solutions are really similar in order to make all subtle differences easily visible, but sometimes one framework provides a unique solution, in which case we are not afraid to use it. The book is divided into four parts that will gradually introduce you to the complexities of PHP frameworks. More experienced developers can freely skip the first part or read only the chapters they need.

Basics

Chapter 1: Introducing Symfony, CakePHP, and Zend Framework—One of the biggest hardships with most frameworks is how to get started. This chapter addresses that problem with a comprehensive tutorial starting with a general discussion of web application frameworks, their structure, and the underlying Model-View-Controller (MVC) pattern. We also briefly present all available frameworks and explain why we chose Symfony, CakePHP, and Zend Framework for detailed comparison.

Chapter 2: Getting Started—Next we move to installation and configuration. We provide instructions for Windows, Linux, and MacOS operating systems for every framework as well as the chosen database and web server. This is a stage in which many things can go wrong and discourage an inexperienced developer, so we are extra meticulous.

Chapter 3: Working with Databases—All frameworks are installed over a database engine, so Chapter 3 is dedicated to mitigating differences between relational databases and the world of object-oriented programming. Then you learn how to communicate with a database from the level of the frameworks, which encompasses constructing an object model with schema files and direct communication with databases through a command-line interface.

Chapter 4: My First Application in the Three Frameworks—Finally some programming. With all frameworks properly configured and running in your favorite environment, it is time you wrote your first application. The address book example presented in this chapter explains how to use tools to develop web applications quickly and efficiently.

Common Tasks

Chapter 5: Forms—This part of the book focuses on the standard elements used by every web developer in his everyday work. The first of these elements are user input forms. You'll start with a simple problem of validating fields and then move on to customizing forms for various application needs. Finally, we'll discuss protection against automated forms submission, namely Captcha.

Chapter 6: Mailing—Mailing is another common task required in nearly all web applications. We need it for user registration, sending announcements, and commercial advertising. In this chapter, several mailing engines will be presented and implemented: SwiftMailer, CakeMailer, ZendMailer, and PHPMailer.

Chapter 7: Searching—This chapter starts with in-depth theoretical descriptions of full-text searching, commonly used algorithms, and approaches. Then we move to practical solutions using the popular search engines Sphinx, Lucene, and Google Custom Search.

Chapter 8: Security—Security issues are always important for a professional web developer. After reading this chapter, you will know how to provide secure connections and defend against the two most dangerous kinds of attacks: server-side XSS injections and client-side cross-side request forgeries (CSRF). We discuss the various types of dangers and introduce security measures.

Chapter 9: Templates—The last thing covered in this part of the book is something everyone should know: how to make a web app visually appealing. In this chapter, we first show you how to create a simple image gallery and then we compare native template engines of the frameworks with add-ons such as the very popular Smarty engine.

Advanced Features

Chapter 10: AJAX—The first of more advanced topics discussed in this part is Asynchronous JavaScript and XML, or AJAX. It allows various features that are both useful and impressive. The first that we discuss is autocompletion of text fields with strings from a given database. The second example is dynamic popup windows for fun and profit, and the third is a simple chat room for multiple users.

Chapter 11: Making Plug-ins—Plug-ins provide advanced functionalities that you need. This chapter discusses creating your own plug-ins. For Symfony and CakePHP, you will write a PDF creation tool, but Zend Framework plug-ins work in a somewhat different manner, so they will be discussed with an appropriate example.

Chapter 12: Integrating Web Services—Web applications cannot live alone. They need integration with other web services and we discuss how to do it here. This chapter discusses the two most common standards, REST and SOAP, as well as providing examples of their use.

Chapter 13: Back end—Most web applications have a content management system (CMS). This chapter shows how to implement simple CMSs and how to use more advanced plug-ins. We also introduce the topic of content management frameworks.

Chapter 14: Internationalization—Internationalization doesn't end with the use of UTF8 character encoding. This chapter covers everything you need to know in order to make a website truly multilingual, including right-to-left languages, user input, collation for sorting algorithms, date formats, and other localization techniques.

Chapter 15: Testing—Quality is the word that best describes the emphasis of this chapter. Testing is a very important part of web application development. This chapter introduces basic testing, including manual and automatic functional tests using the Selenium testing suite; and also black box, grey box, and unit tests.

Chapter 16: User Management—Web 2.0 applications revolve around users, who log-in, socialize, and create content. This chapter discusses efficient and secure ways to authenticate users and grant them access to certain features, starting with Role-Based Access Control (RBAC) and access control lists (ACLs) provided by the frameworks, and then moving on to Lightweight Directory Access Protocol (LDAP), an enterprise-grade solution.

Comparison

Chapter 17: Performance—This last part has fewer chapters than the previous parts, but it starts with an important one. We show here how to use JMeter to run your own customized performance and load tests. We also present two benchmarks made by us: throughput of a simple CRUD application and something even more important: comparison of lines of code written to create this application.

Chapter 18: Summary—The last chapter summarizes everything we have learned in this book. It lists all the pros and cons of each framework, both from a programmer's point of view and the quality of applications that can be developed with their help. And we'll tell you which PHP framework is the best one.

Appendices

We feel really sorry for less-popular frameworks because some of them are really delicious, and we had to focus on three mainstream ones only. However, we added basic info on CodeIgniter, Lithium, and Agavi with some code examples. They are young but very promising, and have good chances to gain great popularity.

There are also a list of interesting web resources for download and further reading, and a glossary of acronyms and technical terms used in the book.

Source Code

The source code presented in this book is designed to illustrate technologies described in the chapters in which it appears. Consistent with the idea that you should be able to freely read the code, not figure it out, the snippets are as simple and informative as possible. We didn't aim to print full listings of all files in the book.

However, we wouldn't leave you without full working applications. They can be downloaded from the Wrox website at www.wrox.com or from a dedicated website maintained by us at www.phpframeworks.org. The advantages of this approach are that we can put all needed files in one convenient downloadable packet. What is even more important is that you can adapt the examples to newer versions of the rapidly evolving frameworks.

To find the source code at the Wrox website, simply locate the book's title (use the Search box or one of the title lists) and click the Download Code link on the book details page to obtain all the source code for the book. Code that is included on the website is highlighted in this book by the following icon:

You'll find the filename in a code note such as this:

Code snippet filename

Because many books have similar titles, you might find it easiest to search by ISBN; this book's ISBN is 978-0-470-88734-9.

Once you download the code, just decompress it with your favorite compression tool. Alternately, you can go to the main Wrox code download page at www.wrox.com/dynamic/books/download.aspx to see the code available for this book and all other Wrox books.

Conventions

Conventions used in this book are pretty intuitive and straightforward. In order to distinguish inline source code from normal text, we are using a monospace font. The same applies to filenames and directories. Names of variables are additionally italicized (unless they appear in code snippets or listings, where they are not italicized). Names of all methods and functions have parentheses at the end in order to make more visible that they are methods; however, their arguments are usually omitted and the parentheses are empty, as in this ExampleMethod(). URLs are monospace_and_underlined.

Snippets of code look like this:

$ zf create model AddressBook

Italic font is used in multiple contexts:

When introducing new terms and important words.When joking and generally not being completely serious.

In the whole book, “Symfony” is always capitalized, like any other specific name, even when referring to 1.x versions, which were called “symfony.” It not only appeals to our aesthetic sense but it is also much easier to find in dense text this way.

Contact Us

We have worked hard to make this book approachable, informative, and bug-free. If you have any comments or suggestions, please let us know. Also, if you find an error, you would do us a favor by telling us about it. More general info about this book, the authors, and an up-to-date list of errata can be found on our website at www.phpframeworks.org.

Also, if you ever wish to buy us a drink for job well done or insult us for massive incompetence, feel free to write us at [email protected].

Contact info for individual authors for more intimate proposals:

: [email protected]

Karol Przystalski: [email protected]

Leszek Nowak: [email protected]

The authors (from left): , Karol Przystalski and Leszek Nowak.

Errata

We make every effort to ensure that there are no errors in the text or in the code. However, no one is perfect, and mistakes do occur. If you find an error in one of our books, like a spelling mistake or faulty piece of code, we would be very grateful for your feedback. By sending in errata, you might save another reader hours of frustration, and at the same time, you will be helping us provide even higher-quality information.

To find the errata page for this book, go to http://www.wrox.com and locate the title using the Search box or one of the title lists. Then, on the book details page, click the Book Errata link. On this page, you can view all errata that have been submitted for this book and posted by Wrox editors. A complete book list, including links to each book's errata, is also available at www.wrox.com/misc-pages/booklist.shtml.

If you don't spot “your” error on the Book Errata page, go to www.wrox.com/contact/techsupport.shtml and complete the form there to send us the error you have found. We'll check the information and, if appropriate, post a message to the book's errata page and fix the problem in subsequent editions of the book.

p2p.wrox.com

For author and peer discussion, join the P2P forums at p2p.wrox.com. The forums are a web-based system for you to post messages relating to Wrox books and related technologies and interact with other readers and technology users. The forums offer a subscription feature to e-mail you topics of interest of your choosing when new posts are made to the forums. Wrox authors, editors, other industry experts, and your fellow readers are present on these forums.

At http://p2p.wrox.com, you will find a number of different forums that will help you, not only as you read this book, but also as you develop your own applications. To join the forums, just follow these steps:

1. Go to p2p.wrox.com and click the Register link.

2. Read the terms of use and click Agree.

3. Complete the required information to join, as well as any optional information you wish to provide, and click Submit.

4. You will receive an e-mail with information describing how to verify your account and complete the joining process.

You can read messages in the forums without joining P2P, but in order to post your own messages, you must join.

Once you join, you can post new messages and respond to messages other users post. You can read messages at any time on the Web. If you would like to have new messages from a particular forum e-mailed to you, click the Subscribe to this Forum icon by the forum name in the forum listing.

For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to questions about how the forum software works, as well as many common questions specific to P2P and Wrox books. To read the FAQs, click the FAQ link on any P2P page.

Chapter 1

Introducing Symfony, CakePHP, and Zend Framework

An invasion of armies can be resisted, but not an idea whose time has come.

—Victor Hugo

What's In This Chapter?

General discussion on frameworks.Introducing popular PHP frameworks.Design patterns.

Everyone knows that all web applications have some things in common. They have users who can register, log in, and interact. Interaction is carried out mostly through validated and secured forms, and results are stored in various databases. The databases are then searched, data is processed, and data is presented back to the user, often according to his locale. If only you could extract these patterns as some kind of abstractions and transport them into further applications, the development process would be much faster.

This task obviously can be done. Moreover, it can be done in many different ways and in almost any programming language. That's why there are so many brilliant solutions that make web development faster and easier. In this book, we present three of them: Symfony, CakePHP, and Zend Framework. They do not only push the development process to the extremes in terms of rapidity but also provide massive amounts of advanced features that have become a must in the world of Web 2.0 applications.

What are Web Application Frameworks and How are They Used?

A web application framework is a bunch of source code organized into a certain architecture that can be used for rapid development of web applications. You can think of frameworks as half-produced applications that you can extend and form to make them take shape according to your needs. Well, that means half your work has already been done, but for some it is as much a blessing as a curse because this work was done in a particular way, without your supervision.

Thus all frameworks are either stained with a coding methodology and naming and structural conventions, or if they try to avoid these restrictions, they need to be heavily configured by you. This either reduces their flexibility or makes their learning curve significantly steeper. And if you really want to escape from these problems toward a more library-like approach, you have to sacrifice some development speed. You can see that frameworks are all about tradeoffs.

That's why it is really good to take a look at many frameworks and compare their differences. Perhaps one of them offers conventions that you would use as good practices, anyway? Perhaps you have nothing against some initial configuration that allows you to be rapid and flexible at the same time? And maybe you want just a library of powerful components to link together by yourself? The choice is yours, and if you find a way to mitigate their disadvantages, you can fully enjoy the greatest benefit of all frameworks: truly rapid development.

Further advantages of frameworks are elegance of code and minimizing the risk of programming errors. Frameworks conform to the Don't Repeat Yourself (DRY) principle, which means that they have all the pieces of logic coded only once in one place. This rule forbids duplication of code, especially copypasting. This facilitates maintenance of code and prevents nasty errors. Generally, frameworks promote code reusability and other good programming practices wherever they can, which is great for programmers who do not have enough knowledge or discipline to care for quality of code by themselves.

Another great feature is the clean organized look of links that can be done with URL rewriting, which is supported by most frameworks. Instead of /animals.php?species=cats&breed=mainecoon, type just /animals/cats/mainecoon. This is not only appealing to the eye but also very search engine optimization (SEO)–friendly.

Framework versus Library

The main difference between a library and a framework is that:

libraries are called from your codeframeworks call your code

In other words, a framework in your application is a skeleton that you fill with features or serves as a platform on which you build your modules. Whereas a library instead provides attachable modules on top of a platform made by yourself. Some people perceive a framework as something better or more complete than a library, so “framework” became a buzzword that is often overused. That's why people call some libraries frameworks, even though they do not invoke developers' code. There is nothing wrong with a piece of code being a library, as it is just a different entity. And there are also some bad frameworks that damage the reputation of the good ones—basically you can take any half-done application, release it, and call it a framework. These two software groups just behave differently and should not be confused.

The application architecture utilized by frameworks is called inversion of control, because the data flow is inverted compared to ordinary procedural programming. It is also referred to as The Hollywood Principle: “Don't call us, we'll call you.” This corresponds to third-party code calling developer's code. The main reason behind it is to make the high-level components less dependent on their subsystems. High-level components pass the control to low-level components, who themselves decide how they should work and when to respond. A good example is the difference between a command-line program, which stops and then asks the user for input, and a program with a windowed user interface, in which the user can click any button and then the window manager calls the program instead.

Some frameworks, such as Zend Framework or CodeIgniter, follow loosely coupled architecture, which means that their components are less dependent on each other and may be used separately, more library-style. Loosely coupled frameworks do not provide development as rapidly as those following a tighter framework architecture and Model-View-Controller (MVC) pattern; however, such an approach allows more flexibility and control over code.

When You Should Use a Framework and When You Should Not

Frameworks are not the cure for all programming problems. Putting aside today's awesome state of development, you should always remember how frameworks were created a few years ago. Most of them were more or less unoptimized junk created by one guy to help him speed up his development process, without much care for documentation, elegance, ease of use, or even readability of his code. Then another group of guys took this code and bloated it with a patchwork of extra functionalities barely consistent with the original code. Then it became apparent that this whole lot needs a solid cleanup in order to be usable, but this would mean either rewriting it from scratch or packaging code in additional wrapper classes, further increasing its unnecessary complexity.

Of course, today the disorganized origin of frameworks is not as evident as before because the quality of code has risen considerably. But still, that's why most beefed-up frameworks have performance issues. That's why they are not always easy to learn. And that's why new ones emerge to cover up weaknesses of older ones. And finally that's why major frameworks provide completely rewritten 2.0 versions, which address all previously mentioned problems.

Advantages

When web application frameworks are useful:

For more or less standard projects with dynamic content, like social networking, online stores, news portals, and so onFor easily scalable applications that can grow from start-up to worldwide popular services without need for big changes in codeFor producing consecutive apps, in which modularity and reusability of pieces of code like controllers and views may be helpfulFor real-world development with deadlines, rotating staff, and fitful customersIf you are, or want to be, a professional web developer, so learning how to work with frameworks is not an excessive effort

As you can see, this applies to most commercial web applications that connect to a database and allow its users to create and modify its content. Therefore, programming with web app frameworks becomes a standard and common practice in the web development world.

Disadvantages

When you should consider development without any frameworks at all:

Purely informative web pages without user-created content, for example an artist's portfolio with fancy graphicsSmall projects with limited database connection that wouldn't benefit much from frameworks' code generationReally big projects that additionally need extreme performance, like the Google suite (you would be using a compiled programming language for that rather than PHP, anyway)With limited hardware resources that call for top performance as well (not really a likely scenario because programming costs are now always higher than hardware costs)Specialist or experimental applications that may evolve in completely unknown direction or work with some custom solutions, like interfaces for scientific experiments with an object-oriented databaseWhen you really need (and can afford) total control over the code and evolution of the applicationWhen you want to create a web app, but you or your co-workers don't want or, even worse, cannot learn how to use a framework

These conditions are generally fulfilled by three types of projects: small static websites, extremely specialist websites, and failed websites. Frameworks are created for development of common web applications with well-known standard architecture. Of course, they may be greatly extended thanks to plug-ins and modules, but complete alteration of their structure may require much painful hacking, so you should always check their capabilities with the design requirements of your project.

PHP versus Other Programming Languages

PHP for many years has been a very popular programming language; however, it was commonly judged as unprofessional. A stereotypical PHP developer was an undereducated freelancer producing cheap, low-quality code. Professionals were supposed to use Zope, ASP, or various Java technologies. Then in 2005 there was a boom of Ruby. Everyone was amazed with the elegance of this programming language; and Ruby on Rails, the central piece of software ever written in Ruby, was claimed to be the ultimate web applications framework. Soon clones of Ruby on Rails began popping out. That's how Python's Django and Turbogears, as well as all PHP frameworks were born.

In 2004 PHP5 was released. It was neat and object-oriented. If somebody still wrote old-styled HTML mixed with pieces of PHP script, it was only his choice, and the programming language no longer was to blame. It took some time, but people gradually considered PHP as a disciplined and professional tool. Together with the modern MVC paradigm and features styled after other frameworks, PHP begun its amazing way to the top of web development applications.

After a few years, it became evident that Ruby on Rails had various limitations. One important limitation was the low availability and high price of Ruby hostings while there was a lot of cheap hosting for PHP everywhere in the world. There was also a great community that eagerly developed early PHP frameworks. This resulted in an IT revolution that dethroned Ruby on Rails as the most popular framework and placed a council of PHP frameworks in its place.

Figure 1.1 illustrates the change in interest in various frameworks over time expressed as search volume in the Google search engine in the Computers & Electronics category. The figure was created with Google Insights for Search, which is a more advanced form of the well known Google Trends tool. You can check these search terms yourself to obtain results beyond mid-2010 (that's when this book was written), at the website www.google.com/insights/search/.

Figure 1.1 Search volumes of frameworks in various programming languages

Open Source PHP Web Frameworks

Another question we want to answer is why we have chosen these three particular frameworks. Are they really better in any way, or are we biased or perhaps have some financial interest in promoting them? Well, starting with that last question, we are completely independent open source enthusiasts and we wanted to compare free (“free” as free speech) software only, so there is certainly no Evil Corporation behind us, and nobody told us which frameworks to choose. We answer the question of whether they're better than other frameworks in the following sections.

There were once closed source PHP frameworks as well, but due to widespread success of the free frameworks, nowadays closed source frameworks are a thing of the past.

Comparison of Popular Interest

We have chosen Symfony, CakePHP, and Zend Framework due to their popularity in the web developers' community, including our own experience in PHP. We believe that open source programming tools show at least some correlation between their popularity and quality because they are used only if they are really useful. In that way they are different from things like proprietary software or pop music, in which quality can be easily replaced by aggressive marketing as the popularity gaining factor.

It turns out that the public interest in web frameworks can be measured quite objectively. Figure 1.2 shows search volumes for various PHP frameworks in Google Insights for Search. You can easily see that there are four leading competitors. All the others combined are less popular than any one of these four. The Lithium and Prado frameworks have been deliberately omitted because their names are nonunique, which generates false positives in trends. We have checked these names in specific categories and found that they are not significant as search terms, either.

Figure 1.2 Comparison of search volumes of different PHP frameworks

When users search for information on a framework, the search results usually reflect talk about it on various blogs and forums, items about learning this technology, and finally developing applications using it. So public interest in a web framework results in real, long-term use of it.

CodeIgniter was really problematic for us. We had a long debate whether it should be included as one of the main frameworks. Perhaps now it is as frequently searched for as Symfony or CakePHP, but what matters more is the area under the graph because it reflects how many people have found the answers they sought and have probably used this knowledge for their projects.

Of course this graph shows nothing more than search volume, and when you see such fast growth it is hard to distinguish a long-lasting trend from temporary hype. We know that CodeIgniter is really good, so it is definitely more than a fad, and perhaps in a year or two it will have its place among the leading web tools.

We finally agreed that three men against four frameworks is not an equal fight. We have not completely forsaken CodeIgniter, though; its features are described, along with Lithium and Agavi, in Appendix b02, where a simple application is developed using each one of them.

The First Look

The first look at the frameworks really gives us little information on their individual features. Their websites just try to impress you with marketing descriptions and a list of features that vary little from one framework to another:

“Symfony is a full-stack framework, a library of cohesive classes written in PHP. It provides an architecture, components and tools for developers to build complex web applications faster. Choosing symfony allows you to release your applications earlier, host and scale them without problem, and maintain them over time with no surprise. Symfony is based on experience. It does not reinvent the wheel: it uses most of the best practices of web development and integrates some great third-party libraries.”

“CakePHP is a rapid development framework for PHP that provides an extensible architecture for developing, maintaining, and deploying applications. Using commonly known design patterns like MVC and ORM within the convention over configuration paradigm, CakePHP reduces development costs and helps developers write less code.”

“Extending the art & spirit of PHP, Zend Framework is based on simplicity, object-oriented best practices, corporate friendly licensing, and a rigorously tested agile codebase. Zend Framework is focused on building more secure, reliable, and modern Web 2.0 applications & web services.”

Now see whether you can spot three differences. Well, the websites are not really informative about unique features of their frameworks. You can find more in various blogs and forums, but still there is little verified data, and general discussions tend to exchange purely personal opinions.

That is why we have written this book. In fact, the differences between frameworks are not really obvious, and it takes some time and practical examples to see them and then harness them in business solutions. Let's begin with some most basic facts.

Symfony

Started: 2005

License: MIT

PHP versions:

Symfony 1.4: PHP 5.2.4+Symfony 2.0: PHP 5.3+

Its logo is shown in Figure 1.3. Website: www.symfony-project.org

Figure 1.3 Symfony logo

Symfony was produced in a French web development company, Sensio Labs, by Fabien Potencier. First it was used for the development of its own applications and then in 2005 it was released as an open source project. Its name was “symfony,” but it is sometimes capitalized (as we do in this book) in order to make it more distinct.

Symfony was based on an ancient Mojavi MVC framework, with some inevitable influences from Ruby on Rails. It also integrated Propel Object-Relational Mapper and took advantage of the YAML Ain't Markup Language (YAML) serialization standard for configuration and data modeling. The default object-relational mapping (ORM) solution has been later changed to Doctrine.

Today Symfony is one of the leading web frameworks. It has a large active community and a lot of documentation—mainly free e-books. Symfony 2.0 is being released in late 2010. It offers various new features and greatly enhanced performance.

CakePHP

Started: 2005

License: MIT

PHP versions: 4.3.2+

Its logo is shown in Figure 1.4. Website: http://cakephp.org

Figure 1.4 CakePHP logo

CakePHP was started in 2005 by the effort of Polish web developer Michał Tatarynowicz. Heavily inspired by Ruby on Rails, CakePHP is an entirely community-driven open source project with lead developer Larry Masters (aka PhpNut). The next major release of CakePHP has also been announced, but its release date is still unknown.

The most important goals of CakePHP are its friendliness, development speed, and ease of use. And it really excels in that. Works out of the box (or oven), with no configuration. It has perfect documentation with working examples for most of its features. And it has really a lot of features to use. That allows the most rapid development with a smaller amount of code.

One of the most controversial features of CakePHP is its compatibility with PHP4. While once it allowed deployment on old cheap hosts that did not support PHP5, now it is more a drawback hindering CakePHP's development. Fortunately, version 2.0 will use PHP 5.3+. There are also reports of CakePHP's really bad performance, but they were mainly due to disabled caching by default.

Zend Framework

Started: 2005

License: new BSD

PHP versions: 5.2.4 since ZF 1.7.0

Its logo is shown in Figure 1.5. Website: http:// framework.zend.com

Figure 1.5 Zend Framework logo

Zend Framework is sponsored by the U.S.-Israeli company, Zend Technologies Ltd., which was cofounded by Andi Gutmans and Zeev Suraski, the core developers of PHP. Strategic partners of Zend Technologies Ltd. include Adobe, IBM, Google, and Microsoft. The company offers various commercial products; however, Zend Framework is an open source project released under the “corporate friendly” new BSD license.

ZF is meant to be simple, component-based, and loosely coupled. This means that it is a library of components, which you can use as you wish, and usage of MVC architecture is optional. This lowers the learning curve and increases its flexibility. The documentation is great, and the source code is of very high quality, both because it's fully object oriented and thoroughly unit-tested. Zend announced an upcoming 2.0 version as well, but its release date is still unknown.

Other Frameworks

There are hundreds of PHP frameworks. This is not an exaggeration if you count all of them, including ancient and already abandoned projects, as well as brilliant younger startups and some useless short-lived junk. The web app market is a big one, but the amount of PHP tools is disproportionally huge and perhaps somewhat excessive. Here is an overview of a few more notable ones that we have found to be used successfully to develop web applications.

CodeIgniter

Started: 2006

License: modified BSD

PHP versions: 4.3.2+

Its logo is shown in Figure 1.6. Website: http://codeigniter.com

Figure 1.6 CodeIgniter logo

CodeIgniter is developed and maintained by a privately-owned software development company, Ellis Labs. It is focused on having a very small footprint, while allowing a big increase in performance. It follows the MVC pattern only partially, for the models are optional. It is loosely coupled and in the words of Rasmus Lerdorf, it's “the least like a framework.” Its lightweight approach has earned a wide recognition in the developers' community, but it is sometimes criticized for conformance with PHP 4.

CodeIgniter is a good choice for less complex web applications that would benefit from using a framework, but the heavier ones would either hinder the applications' performance with excessive features, or their configuration would take too much time. The structural simplicity of CodeIgniter makes it also a frequent pick by beginners who choose it as learning platform before moving to a full MVC framework.

Lithium

Started: 2009

License: BSD

PHP versions: 5.3+

Its logo is shown in Figure 1.7. Website: http://lithify.me

Figure 1.7 Lithium logo

Lithium took all the best that CakePHP had to offer and moved it to PHP 5.3. First it was a branch of CakePHP called Cake3, now it is a separate project run by some former CakePHP developers. It is lightweight, fast, and extremely flexible with extensive plug-in support. It has many truly experimental and innovative functions like a filter system and an integrated test suite.

The second search result Google showed us for “Lithium framework” is a page titled “CakePHP is dead…Lithium was born.” This claim is still far from true, however, with the advantages provided by Lithium's support for PHP 5.3, Lithium may really endanger CakePHP in the future unless the latter takes immediate action.

Agavi

Started: 2005

License: LGPL

PHP versions: 5.2.0+ (recommended 5.2.8+)

Its logo is shown in Figure 1.8. Website: www.agavi.org

Figure 1.8 Agavi logo

Like Symfony, Agavi is based on the Mojavi framework. It was started in 2005, but the 1.0.0 version was worked upon until early 2009. The source code is very polished and sometimes called the best-written MVC OOP framework. However, it has not gained much popularity, perhaps due to scarce documentation.

It was never meant to be popular. The authors stress that Agavi is not a website construction kit, but a serious framework built with power and extensibility in mind. Its target applications are long-term specialist projects that need full control of their developers.

Kohana

Started: 2007

License: BSD

PHP versions: 5.2.3+

Its logo is shown in Figure 1.9. Website: http://kohanaphp.com

Figure 1.9 Kohana logo

Kohana is a community-supported offshoot of CodeIgniter. In contrast with CodeIgniter, Kohana is designed for PHP5 and is fully object oriented. While boasting higher elegance of code, it still has all the qualities of CodeIgniter: It is extremely lightweight, flexible, and easy to learn. The community behind Kohana is large and active, so despite its young age it should be considered a stable and reliable framework.

Prado

Started: 2004

License: revised BSD

PHP versions: 5.1.0+

Its logo is shown in Figure 1.10. Website: www.pradosoft.com

Figure 1.10 Prado logo

Prado stands for PHP Rapid Application Development Object-oriented. It enjoyed moderate popularity some time ago, but now its development seems a bit sluggish. However, it is still a mature framework well-suited for most business applications. One of its interesting features is that it nicely supports event-driven programming. It has some similarities with ASP.NET.

Yii

Started: 2008

License: BSD

PHP versions: 5.1.0+

Its logo is shown in Figure 1.11. Website: www.yiiframework.com

Figure 1.11 Yii logo

Yii was founded by a developer of Prado and it continues many of its conventions. Yii is very fast (leading in most benchmarks) and extensible, modular, and strictly object oriented. It has a rich set of features and decent documentation. It uses no special configuration or templating language, so you don't have to learn anything apart from object-oriented PHP to use it. Also, unlike many other frameworks, it follows pure MVC architecture with data being sent directly from Model to View.

Akelos

Started: 2006

License: LGPL

PHP versions: 4 or 5

Its logo is shown in Figure 1.12. Website: http:// www.akelos.org, http://github.com/bermi/akelos

Figure 1.12 Akelos 2 logo

While all PHP frameworks are more or less inspired by Ruby on Rails, Akelos aims to be its direct port. It is focused on internationalization (provides multilingual models and views as well as Unicode support without extensions) and can run on low-cost shared hostings (that's why it has support for PHP4).

The author of Akelos announced the completely rewritten Akelos 2. It drops support for PHP4 and uses autoloading and lazier strategies for loading functionality. Its hallmarks will be advanced routing methods and strong REST orientation (REST is described in Chapter 12). It is to be released in late 2010 and it looks very promising.

Seagull

Started: 2001

License: BSD

PHP versions: 4.3.11+

Its logo is shown in Figure 1.13. Website: http://seagullproject.org

Figure 1.13 Seagull logo

Seagull is a true veteran among PHP frameworks—it was founded in 2001. Years of development made it solid, stable, and tested. It is no longer actively developed, so perhaps it is not the best choice when starting a new project, but there are still numerous successful applications that were built with it. It has contributed greatly to the development of all other PHP frameworks.

Qcodo

Started: 2005

License: MIT

PHP versions: 5.x

Its logo is shown in Figure 1.14. Website: www.qcodo.com

Figure 1.14 Qcodo logo

Qcodo is an MVC framework that excels in code generation from database design. It has a very powerful code generator that analyzes the structure of the data model, and creates PHP object code and also HTML pages for database manipulation. Perhaps this is not one of the more popular frameworks you are likely to hear about during a casual conversation, but several top institutions (including NASA) have applied it for their projects. Qcodo was created by Mike Ho of QuasIdea Development and is now developed by an active community. It also has a completely community-driven fork called Qcube.

Solar

Started: 2005

License: New BSD

PHP versions: 5.2+

Its logo is shown in Figure 1.15. Website: http://solarphp.com

Figure 1.15 Solar Framework logo

SOLAR stands for Simple Object Library and Application Repository. Its structure and naming conventions are similar to those of Zend Framework. One of the biggest differences is how you construct objects—all are created with a unified constructor and configured with an array in a config file. It has many helpful built-in example applications.

PHP On Trax

Started: 2007

License: GPL

PHP versions: 5.x

Its logo is shown in Figure 1.16. Website: www.phpontrax.com

Figure 1.16 PHP on Trax logo

As the name cleverly suggests, this framework was designed as an exact PHP copy of Ruby on Rails. At least it was meant to be because it still lacks many features and it is highly unlikely that it will finally realize this goal. It is just one of many good-looking frameworks that have eventually failed.

Design Patterns in Web Frameworks

There are certain abstractions that can be transported between applications in order to make the development process faster. This section takes a closer look at these abstractions and the way they shape the web application frameworks.

It is not absolutely necessary to understand design patterns in order to start working with frameworks, so if you are bored, you can skip to the next chapter and come back here later. However, design patterns are fairly fundamental to these frameworks and application development as a whole, so we insist that you really come back here if you decide to skip this section now.

What Is a Design Pattern?

The definition of design pattern states that it is a general solution to a commonly occurring problem in software design. There is really not much more formal foundation because design patterns are a generally practical means that make up for a lack in formal mechanisms. Most often they are created when programming languages do not provide abstract mechanisms that become undeniably useful during the development of real-world applications.

A good analogy for design patterns is the game of chess. A novice player needs just to know the rules. It's like learning the basic syntax of a programming language. Still, knowing how a bishop moves doesn't make you a successful chess player, just like knowing how to open braces doesn't make you a PHP programmer. Skilled players are able to predict a few moves forward and respond with a winning scheme. That's like an experienced programmer who can, in fact, produce working software.

As you begin to master the game of chess, you begin to see patterns emerging. You can barely glance at the chessboard to classify the situation into one of these patterns and provide a proven response, both for present and future risks. You can perceive these patterns just intuitively, or you may try to name them. It's the same with software design patterns: when you are truly proficient, you use them all the time. There is a good chance that you have used some of them without even knowing it.

Naming design patterns is not necessary, but is indeed good for two things. First is an aid for thinking with patterns, because when you name something abstract, it is much easier to implement it in practice. Then you may further analyze this pattern, draw diagrams of it, and take full advantage of it. And the other thing is that you can share your experience. Chess players love to talk about various openings and gambits, and programmers can learn a lot by exchanging knowledge of design patterns as well.

And even more important, if you want another programmer to add some functionality to a fixed class and then tell him to use the Decorator pattern, you can expect that it will be done the way you want it rather than with a random makeshift solution. Thus design patterns have a great potential for preventing future problems.

Model-View-Controller as the Main Structural Design Pattern

Web frameworks take advantage of most, if not all, design patterns. However, MVC is the absolute structural backbone of all frameworks. The main idea of MVC is dividing the application into three layers:

Model—Represents the business logic of the application. It is more than just the raw data; the Model has to represent the structure of data with all relationships and dependencies. It may comprise one or more classes that correspond to logic objects of the application and provide an interface for manipulating them. The Model is the only layer that uses persistent storage. It should completely encapsulate all database connections. The model should also notify the View when its internal state changes, so the View can be refreshed.View—The output displayed to the user. The most important thing is that the View never modifies the application data; it only presents it. There may be multiple Views for the same data, such as traditional HTML, PDF, Flash, or WML for mobile devices. They should be interchangeable without modifying the other layers.Controller—The part of an application responsible for handling user interaction and taking all other actions. The Controller should be created with simplicity in mind—it should be the controlling part that uses methods provided by the Model and the View; it shouldn't do everything by itself.

Figure 1.17 illustrates the relations between the three layers.

Figure 1.17 Model-View-Controller pattern

MVC versus MVP

MVC is an old design pattern, dating back to the 1979 work “Applications Programming in Smalltalk-80: How to use Model–View–Controller.” by Trygve Reenskaug. Since that time, it was often used in non-web applications, mostly graphical user interfaces in compiled languages like C++ or Java. There it was easy and natural to implement an exact MVC pattern, but for web applications, it was somewhat modified.

Model-View-Presenter (MVP), shown in Figure 1.18, is a derivative of MVC. It is a three-tier application structure, where the Presenter acts as a middle layer between the View and the Model. The Presenter differs from the Controller in that it loads data from the Model and delivers it to the View.

Figure 1.18 Model-View-Presenter pattern

Most so-called MVC frameworks follow the MVP pattern. While it is not bad itself because MVP seems even better suited to the task, this naming convention may be somewhat confusing. As long as MVP is derived directly from MVC, it is not a big problem, so in this book we will follow the names conferred by the authors of the frameworks. So we will call all frameworks Model-View-Controller, even if the Controller does the majority of data-transferring work.

Overview of Other Design Patterns

Design patterns can be divided into creational, behavioral, and structural patterns. Full description of all design patterns is well beyond the scope of this book, but you can find it in the most influential book on this subject: Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the Gang Of Four). However, we want to provide you with just a short overview of design patterns that are commonly used in web frameworks.

Singleton

This design pattern, which is so trivial it is often called an antipattern, is very useful. The purpose of the Singleton pattern is to ensure that a class has only one instance and to make this instance globally accessible. Whenever another object needs access to the Singleton, it calls a static, globally accessible function that returns reference to the single instance. You can see the structure of the Singleton in Figure 1.19.

Figure 1.19 Singleton pattern structure

The trick behind Singleton is to make the instance and all its constructors private. So there is no way to demand creation of a Singleton