NetTuts.com has posted the latest part of their "Programming with Yii2" series today that dives deeper into the functionality of the framework and investigates the use of MVC forms and layouts.

In Programming with Yii2: Getting Started, we set up Yii2 locally, built a Hello World application, set up a remote server, and used Github to deploy our code. This tutorial will cover some of Yii's more basic concepts related to its implementation of the MVC framework: Models, Views and Controllers. We'll also explore layouts and customization of navigation menus and Bootstrap elements.

They start with a look at the model functionality Yii2 has to offer and creates a first simple model, the "Status" model, to evaluate permission status. Next up is a simple controller, one that handles incoming status requests and either creates the record or displays the information in the model. Next is the output part of the application with examples of view handling, forms and layouts.

In response to a recent post from Anthony Ferrara about MVC Paul Jones suggests that Anthony's view that it and related structures "all pretend to be application architectures" is false.

The central mistake I think Anthony makes is near the end of this post, where he states (in talking about MVC, ADR, et al.) that "All Pretend To Be Application Architectures." That assertion strikes me as incorrect. While it may be that developers using MVC may mistakenly think of MVC as an application architecture, the pattern description itself makes no such claim. Indeed, Fowler categorizes MVC as a "Web Presentation Pattern" and not as an "Application Architecture" per se. [...] Fowler's categorization and description of MVC define it pretty clearly as a user interface pattern. ADR, as a refinement of MVC, is likewise a user interface pattern.

He goes on to talk more about the ADR (Action-Domain-Responder) pattern, how it's more of a user interface pattern as well and how that relates to using it for HTTP requests. He suggests that the definition from Anthony may be a bit too broad and proposes the alternative "All Are User Interface Patterns, Not Entire Application Architectures" to be a bit more specific.

Lee Blue has posted his next article in a series covering some of the real costs and considerations around using PHP for your applications. In this latest post he talks about frameworks and what kind of effect they could have on the overall profitability of your business.

Last week we talked about application shelf life an aspect of PHP development that often goes overlooked. This week let's talk about how the web development framework you use contributes to the shelf life of your app and the profitability of your web application. [...] The main goal of all web frameworks is to improve the developer's ability to get ordinary things done so we can focus on the primary goals of what we're building.

He talks about how PHP was "made for the web" and why there are so many different kinds of frameworks out there (though most are generally MVC-ish). He talks about one of the standard arguments, learning curve vs efficiency, and how it compares to the "no framework framework" ideals. He then gets into some of the dark side of using frameworks, specifically how they can shorten the shelf life of an application and how difficult migration can sometimes be. He points out the irony of large frameworks: the bigger the app/framework, the harder it can be to migrate (and cost more). He encourages sticking with smaller, lighter frameworks instead and suggests coding standards, common packages and using custom libraries only where needed to create your application.

Anthony Ferrara has posted another in his series looking at MVC as a design pattern and as an idea for building web applications. In this latest post he goes on to make a point about MVC, how it relates to architecture and CRUD.

Last week I post a post called Alternatives To MVC. In it, I described some alternatives to MVC and why they all suck as application architectures (or more specifically, are not application architectures). I left a pretty big teaser at the end towards a next post. Well, I'm still working on it. It's a lot bigger job than I realized. But I did want to make a comment on a comment that was left on the last post.

He responds to the comment (essentially that CRUD is a solved problem) and where the need for customizations is needed. He suggests what the real problem is, though: the three classes of developers - CMS users, custom developers and users of both.

Following up on his previous article talking about the MVC design pattern (and the idea of "MVC"), Anthony Ferrara has posted some alternatives to MVC for your consideration. These other options are mostly variants of the typical MVC structure and could be considered "siblings".

Last week, I wrote A Beginner's Guide To MVC For The Web. In it, I described some of the problems with both the MVC pattern and the conceptual "MVC" that frameworks use. But what I didn't do is describe better ways. I didn't describe any of the alternatives. So let's do that. Let's talk about some of the alternatives to MVC...

He starts by restating some of the major issues with the typical MVC implementation (three of them). From there, he covers each of the alternatives with a summary paragraph or three about each:

He talks about the similarities between them, mainly that they're all "triads" of functionality and that they all have the same basic purpose. He also suggests that they're all "pretending" to be application architectures.

If it's not clear where something fits in your application, that's a sign that your application architecture is flawed. Not that you need to introduce some magic in to get it to work. So let's admit that none of these are application architectures... And let's admit that there is a problem we need to solve.

Anthony Ferrara has posted what he calls a beginners guide to MVC for the web, a tutorial that introduces to you the basic concepts behind the Model-View-Controller design pattern and how it should fit in with the SOLID design principles.

There are a bunch of guides out there that claim to be a guide to MVC. It's almost like writing your own framework in that it's "one of those things" that everyone does. I realized that I never wrote my "beginners guide to MVC". So I've decided to do exactly that. Here's my "beginners guide to MVC for the web".

He starts with his first lesson, his most important one really - you don't need "MVC" (the concept, not the pattern...he notes them differently). He then gets into what the MVC pattern actually is and describes each piece and how they fit together. Following that, he talks about "MVC" as a concept and how it's different from MVC, the design pattern (hint: the pattern describes one implementation of the MVC ideals). He talks about the role of state in the MVC structure and how the implementation of the MVC idea is slightly different in the various "MVC frameworks" out there.

There is a very useful lesson that MVC brings: Separation Of Concerns. Meaning that you should separate different responsibilities into different sections of your application. Separation of Concerns is a necessary step in dealing with Abstraction. Instead of latching on to MVC, latch on to abstraction. Latch on to separation of concerns. Latch on to architecture. There are far better ways to architect and abstract user interaction for server-based applications than MVC.

The SitePoint PHP blog has kicked off a new series of posts today with the first tutorial about building an application with OOP and the Slim framework. In this starting article they focus in on bootstrapping the application and introducing some of the basics behind MVC and OOP.

At a certain point of my development as a PHP programmer, I was building MVC applications by-the-book, without understanding the ins-and-outs. I did what I was told: fat model, thin controller. Don't put logic in your views. What I didn't understand was how to create a cohesive application structure that allowed me to express my business ideas as maintainable code, nor did I understand how to really separate my concerns into tight layers without leaking low-level logic into higher layers. I'd heard about SOLID principles, but applying them to a web app was a mystery. In this series, we'll build a quiz application using these concepts. We'll separate the application into layers, allowing us to substitute components: for example, it'll be a breeze to switch from MongoDB to MySQL, or from a web interface to a command-line interface.

They start off with a bit about why "MVC is not enough" and how they'll be applying domain modeling as a part of the application. There's also a brief mention of the concept of a service layer and how it will fit into the overall structure. Then it's on to the code: getting Slim installed (via Composer) and starting in on the interface/service classes for the Quiz. They walk you through entity creation for the Quiz and Question instances and a mapper to tie them together.

On the SitePoint PHP blog today they've posted a new tutorial that reintroduces you to FuelPHP, the framework that was (sort of) the successor to the CodeIgniter framework. It was started by some of the ex-CI developers in an effort to make a more robust, yet simple PHP framework for PHP 5.3+.

As a PHP developer, I have been a consistent user of different PHP frameworks, mostly focusing on CakePHP. Recently, I felt the need to go framework shopping and I have many valid reasons for choosing FuelPHP. It has a built-in modular structure and complete flexibility with emphasis on community. Before Fuel, I was a CakePHP user and just like Cake, Fuel is a huge community driven framework.

The author walks you through the installation process (via the framework's own "oil" command line tool) and dives into some example code quickly after that. He shows how to create a simple "Hello World" route and generate the scaffolding (code generation for the MVC pieces) including migrations. He creates a simple "users" table and adds some authentication checking to the controller. Then in the view he sets up a simple login form, requesting username and password and outputting any errors that might pop up during the authentication process.

i recently got a new job and whilst I'm working my notice period I've been tasked to find my replacement. One of the big questions my boss has is whether a developer would mind taking over a MVC framework I built specifically for the company. (I would explain why we didn't use Laravel / Symfony / Zend etc. but that's a whole post in itself). The framework is conventional and should feel familiar to someone with Laravel experience... But at the end of the day it's totally proprietary. It's built to PHP-FIG standards and would come with full documentation. So, would you have any issues taking the job, or would you be put off?

There's opinions shared that lean both ways, but there seems to be a large majority that strays more heavily into the "no" column. They suggest that, with all of the great and well-developed PHP frameworks already out there, a custom one would probably cause more problems that it solves. While there's plenty of technically oriented comments, there's also a few that are more "high level" looking at the reasoning for taking the job (hint: it's not just about technology) and what the needs/requirements of the business are.

Paul Jones has a new post with more information about his proposed "Action-Domain-Responder" design pattern (a replacement for the typical MVC) and suggests a new piece, the Domain Payload pattern. This pattern would use a domain payload object to wrap the data and provide the responder with additional handling and context.

In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.

He shows a code example of this Domain Payload object in action, starting with some typical MVC code and refactoring it along the way into an ADR structure. He shifts from a typical model into a more domain-driven approach and describes the wrapping of the data in the payload, context for the contents (even just a class name helps) and how those relate to the actual output. You can find the resulting code in this example over on Paul's GitHub account.