Security is a part of our work as developers. We need to ensure our applications against malicious attacks. SQL Injection is one of the most common possible attacks. Basically SQL Injection is one kind of attack that happens when someone injects SQL statements in our application. You can find a lot of info about SQL Injection attack. Basically you need to follow the security golden rule: "Filter input, Escape output".

He advocates the use of the PDO abstraction layer to filter out a lot of the issues. Using its prepared statements, you can easily strip out things that just adding slashes to user input wouldn't prevent. He also includes a reminder about database permissions - allowing only certain users the ability to, for example, delete can help provide one more level of security (in other words, don't use a "super user" in production).

To help better explain each of the three aspects of DI I discussed in the previous article I'll be going over each more thoroughly and with those code examples requested. I'll be going through each point one at a time as the explanations will likely be of some length compared to the original post.

He starts with the "villain" of the story - the Singleton design pattern, a difficult to test method that lulls you into thinking you're not in the global scope. He talks about the problem of using this approach and how the Factory design pattern can be used to create an alternative. He changes up the example to create a "DbTableFactory" class that can be used to create the objects needed - in this case a "UserTable" object with the connection injected into it at construct time.

This article will show how we can develop software in php with a nifty design and architecture, and very much like other languages like java, using an ORM and an AOP, DI, Events container. I will assume you've read (or at least took a quick look) at this article that explains the tree layout used throughout the code, and that you have some basic knowledge of Doctrine2 and used it before on your own.

He starts with the result - an easy to use, self-contained (and decoupled) system for accessing the Doctrine2 instance. It's event-driven and uses Aspect-oriented programming to mange interactions between components (or as he calls them "beans"). Code is included for the entire process for a logger, the User entity, entity manager, user repository and transactional aspect. You can find the complete source for his example on his github account.

Dependency Injection is just a fancy term for passing dependencies to the object needing them instead of letting the object create its own. Hopefully, you've watched this great Google Clean Code talk about dependency injection by Misko Hevery where he talks about why you should ask for things instead of looking for them. I'm gonna talk about some reasons to use DI beyond just those presented in the video.

He breaks it up into a few different sections:

• It helps in the battle against global state
• It helps your design
• It makes using the single responsibility principle easier

Does it means that we have to make a choice between flexibility, customization, ease of testing and not having to copy and paste the same code into each application front controller? As you might expect, there is a solution. We can solve all these issues and some more by using the Symfony2 dependency injection container.

The Symfony2 DIC (DependencyInjection) allows you to create a container with the objects and settings that you want and inject that into the main "Framework" class for its use. He registers most of the components he's added over the series like the UrlMatcher, RouterListener, ExceptionListener, EventDispatcher and the Framework class itself. This is all stored in a separate file(s) and can be conditionally included based on your environment. He shows how to register a custom listener, add parameters to the DIC configuration.

If you're looking for an approachable guide that teaches you how to implement an easily-customizable service layer in PHP, then take a peek at this article series. In a step-by-step fashion, it walks you through the development of a sample web application, which uses a service to perform CRUD operations on a domain model composed of a few user entities.

Service layer types covered in the series are:

• Working with database entities
• Data Mappers
• Database adapters
• Handling Entity Collections
• User Services
• Dependency Injections
• Modeling Domain Objects

If you've been watching the PHP weather vane (we call it Twitter for short), you may have noticed a shift in Symfony and Zend Framework. Version 2.0 of both web application frameworks feature Dependency Injection Containers (DICs) as the primary means of creating the objects (and even Controllers) your application will use. This is an interesting shift in a programming language that often stubbornly evaded adopting DICs to any great extent.

He introduces dependency injection (DI) as a method for "injecting" objects and configurations into other interfaces without any specific kind of relation between the two. Part of several DI implementations is a container that does some of the magic object creation for you. He applies this concept to a Zend Framework structure and talks briefly about why these containers are "the devil" because they (usually) add complexity where none is needed. He points out one container library, Pimple, that gets it right in his opinion - defining object creation as closures. In the next part of the series, he'll compare the Zend Framework's DI setup against Pimple (and Symfony's) implementations.

Today I ran into a little issue: how to pass generic logger object to method? I wanted to get some verbose output from method, which I call from Command, but onc time it should log with Symfony2 OutputInterface and other time it should use monolog logger. Of course I can make some wrapper class for both of them, but it would be kind of an overkill. The Closure from PHP 5.3 came with solution.

His alternative creates a closure for his Symfony2 application that defines the logger handling in an abstract way and injects that object into his job queue manager for handling. This way the manager doesn't have to worry about handing the mailing itself, it's just deferred to the mailing object. You can find out more about this technique, dependency injection, here.

Symfony's DependencyInjection component is a PHP implementation of a Service Container, or as others like to call it, a Dependency Injection Container (DIC). The component also provides useful tools for handling service definitions, like XML loaders or dumpers. If you want to learn more about the dependency injection or the dependency injection container, read an excellent series of articles on the subject by Fabien Potencier: What is Dependency Injection?

He walks you through the entire process - installing the needed libraries (the DIC, a config and class loader component and Buzz, a lightweight HTTP client). Code is included to show object creation the "usual way" and then creating the same types of objects in a dependency injection environment. Also included is a sample XML document describing the services for the container. He finishes the post with a GraphvizDumper-generated image for the container.

I am currently working on some Symfony2 bundles, I needed a custom repository to house hold my custom queries, that part is easy with sf2, and quite nicely explained in the Manual.

He walks you through the setup of a simple custom repository (a part of a Code4Hire bundle) and a (less elegant) call that can be used to reference it and its methods. To make things a big more clean and take advantage of the full dependency injection features of the framework, he makes a change to move the repository into the services.xml. This defines the container and makes it available to the application directly in function calls (like his render() example near the end of the post).