have recently been writing a collection of PHP components exploring different design patterns for building applications. With the MVC layer close to completion I decided to write a couple of guides on how these components could be wired together to achieve several different application formats. First in this series will highlight the power of OrnoDi when used to resolve your objects, to do this we will be building a simple RESTful api with the minimal amount of configuration and bootstrap code.

He includes instructions to install the components (via Composer) and configure the DI container with the needed settings. He shows examples of the autoloading setup, how to handle the routing and how to create the sample model and controller to respond to the sample REST requests.

Welcome to part 2 of this two-part series discussing MVC and PHP, where we'll discuss some of the considerations one must make when using an MVC architecture. If you've come straight to this article without reading part 1 first, I encourage you to head back and have careful read as this one will assume that you've read and understand everything it discussed.

He talks about some of the things more involved in making a MVC framework including routing and URL formats and working with templates. Sample code is included for the route handling, model/controller relationship and view classes for the templates.

The Model-View-Control (MVC) pattern, originally formulated in the late 1970s, is a software architecture pattern built on the basis of keeping the presentation of data separate from the methods that interact with the data. In theory, a well-developed MVC system should allow a front-end developer and a back-end developer to work on the same system without interfering, sharing, or editing files either party is working on. [...] In this article, I will go the basic principles of MVC, a run through the definition of the pattern and a quick example of MVC in PHP. This is definitely a read for anyone who has never coding with MVC before or those wanting to brush up on previous MVC development skills.

He starts with an introduction of the overall structure of the pattern, how each part talks with the others. He then talks about each piece in a bit more detail and provides some code examples for some very basic MVC classes. There's no routing or anything connected to them like there would be in a framework - it's just the classes taking the others in as parameters.

When choosing a PHP framework you need to make sure that it emphasizes features which are the most important to you. If you are looking for something fast, simple, and easy to learn than PHPixie may be a perfect choice. To illustrate the basics of developing with PHPixie we will create a small polling application. By the end of this tutorial you will have a working poll application and an understanding of how easy it is to code projects using PHPixie.

They provide you with all of the parts you'll need - the database table definition, the code for the modules/views/controllers and the Javascript to handle the addition of new options. You can find the full code on the PHPMaster github account.

In this somewhat risqué episode, we'll look at just what you need to be able to do development work on the i. Many people in the i world will that PHP is native to the i, but I don't think that's really true. To me, native means that it just runs, no problems or questions asked, nothing special needs to be done, it just sort of happens like when you see someone across a crowded room and know she/he is "the one". That's not the way it works with PHP and the i.

He starts off by talking about Zend and its contribution to the IBM i's abilities to run PHP through RPG thanks to a "bridge" they created. There are other options, but as he points out, they're not as well developed (or supported) as Zend's offering (being Zend Server, Zend Studio and Zend Framework).

He then talks about the details of creating and running scripts - where to put them, what kind of RPG knowledge you'll need to implement them, and which parts of the typical MVC stack work best where.

In the initial entry in this series, we took care of the UI-aspect of our Twitter-clone, called Ribbit. Now, we'll begin coding the application in a number of languages. This lesson will leverage standard PHP (with homegrown MVC), but, in future articles, we'll review other implementations, such as with Rails or Laravel.

They provide all the code you'll need, the database table structure to power it (MySQL) and the examples of a model, router and basic MVC stack to handle the requests. They help you make a user creation and login system as well as a few other pages ("buddies", "make a post" and a few others). You can also download the source from their Github account if you want it all in one shot.

I decided to pick CodeIgniter back up and start really trying to learn the ins and outs of it. I was pleasantly surprised that overall, it is pretty simple to use and whenever you want to do something, the first question to ask yourself should be "Let me check the user guide and see if there is a library or helper for this before I write it". Chances are, the answer has already been thought of and exists in the framework.

The post is pretty high level and describes the parts of the MVC structure (Model/View/Controller) and how they relate to the features that CodeIgniter has to offer. For more information about this framework (and downloads) check out codeigniter.com.

The question is: where is Model layer in Symfony2? My answer is: there's ain't one and it's good.. Symfony2 isn't hardly bounded with Model layer, as it could have been seen in first version. We can see many Active Record model implementations in modern web frameworks such as Ruby on Rails, Django and symfony 1. I'm not saying those solutions are bad. The main problem was, that big systems maintained by plenty of developers changing over time tends to have a messy codebase. The common place to locate business logic were Model layer. The result of that approach were huge model classes, randomly structured Table/Peer classes full of static method and general feeling that system is hardly impossible to maintain anymore.

He talks about the main problem that comes from this style of coding - overly complex systems - and one possible way to help mitigate them using domain-driven design practices. He lists a few of the things that Symfony2 comes with that could be helpful for this method including the dependency injection container, the use of entities, repositories and value objects.

To overcome your skepticism [of an easy to use, flexible view system], in this two-part tutorial I'll show you how to implement from scratch a couple of customizable view handling modules by sinking our teeth into the goodies of the Composite and Decorator patterns.

He starts off by creating a foundation to work from - a basic View class that takes in data, allows for the setting of a template and combines it all together when "render()" is called. He then takes this example and applies the Composite pattern and creates interfaces for the template, container and view, implements them and shows how to attach views to other views. Each of these views is then rendered when the main "render()" method is called and the output is appended.

In the Reddit comments most people share the similar ideas about the results:

• "I don't put much stock in hello world bench marks for MVCs. If you just need "Hello world" then write it in html."
• "Asking which framework is the fastest is almost irrelevant in most cases. I always dislike benchmarks like this because the actual situation is so much more complicated than a handful of benchmarks can show."
• "Any decent framework can output a simple content page from cache, it should not even have to call any router or controller. That's why simple content benchmarks are useless."
• "Who cares? The speed of a language or framework does not translate over to the speed of your website. What matters is your architecture."

If you're looking for benchmarks that are more useful than these, I'd suggest checking out (and maybe contributing to) the ones Paul Jones has created over on Github.