My MVC Rant! lol

PHP
1

I’ve always shy’d away from MVC I personally don’t like using other developer codes definitely when i don’t know what exactly is going on through the 50,000+ lines of code.

Since 2009 I’ve tried numerous MVC Frameworks and always, steered back to my style, which was pretty efficient it was basically a Model / View style.

So finally I’m like let me just develop my own MVC structure I took a week to myself and studied MVC pattern development. Bumped into the problem i always bumped into which is, URL flexibility, file structure flexibility and just flexibility in general like using classes out side the MVC framework. So i decided to take my style and MVC style mix it up a bit. I’m loving the way this is coming together.

In short… I still personally think MVC is an over kill. I still don’t see the point in creating a Controller (Index) then Create a Model (Index) and the a View (Index) i still see it as redundant effort. The standard URL structure with all the Frameworks (Controller->Method->Param 1 , Param 2, Param 3, Param 4) limits any robust application. Which forces a work around for a URL Router.

Other thing i didn’t like about MVC is silly helpers like Create_Link(‘#’, ‘_target’, ‘Name Of Link’); Its easier to me just to type <a href=“#”> Name Of Link</a>

I still don’t understand why people download CodeIgniter, Zend, Yii… The download alone is over 10mb+ in just straight useless code, in which about 10% is used on a standard application. Before you even start getting a site together the performance is dead.

I think i feel better. :slight_smile:

2

I have never used a MVC but it always seems a waste to me - it is also more code to learn!

The download alone is over 10mb+ in just straight useless code, in which about 10% is used on a standard application.

I feel the same way about template engines, galleries etc. most people only use a tiny amount of the options. A few years ago when I started out I was interested in some code and in itself it was not very large; but then you needed to use the smarty template engine to display the results which was considerably larger than the original code :rolleyes:

3

The idea is separate the concerns of the application, to help you create code which is more maintainable and reusable. You could just lump things together, and that approach will get you so far for quick and dirty scripts, but it’ll become increasingly difficult to maintain for anything else that’s likely to grow over time.

The controller keeps the web specific aspects of the application (dealing with input from $_POST, $_GET etc) away from your model, which shouldn’t know anything about these things. Ideally your controllers won’t contain a lot of code, as all the business logic for your app lives in the model layer.

The model layer is the core of your app, it encompasses all the logic for doing whatever it is your app is designed to do, but importantly it doesn’t know about where the input comes from or how to display output.

The view is solely responsible for the display of data returned from your model layer. It should only contain logic that’s involved in how to display output. Keeping this separate from your model means that you can easily handle different kinds of output (as HTML, JSON, XML, or via the command line) without having to touch your model.

Most of the frameworks I’ve used don’t limit you to a structure like that. You can construct routes which allow you to use any kind of URL structure you want.

Performance does vary widely between frameworks (I’ve heard it said that Zend is one of the slowest), but from a business perspective, hardware is cheaper than developer time. Using a framework eliminates a lot of boilerplate from common tasks, and allows other developers to drop into a project and have a head-start with knowing how everything is set out, and where they can find things.

To be fair, I dabbled with v1 of the Zend Framework and I can sympathize with what you’re saying, the codebase did seem bloated and overly complex. Remember though that there are frameworks of all shapes and sizes out there - while some are highly opinionated and all encompassing, there are also many so-called microframeworks (check out Slim, for example) which don’t try to do everything and don’t get in the way of how you want to write your code, they just provide a base to build off.

4

I wholeheartedly agree. Thankfully, this kind of rigid URL structure isn’t inherent to MVC. And as fretburner pointed out, not every framework works that way.

Same. MVC doesn’t inherently mandate any file structure. Some frameworks are very rigid; some are more flexible.

I agree. Those are pretty silly. Fortunately these aren’t inherent to MVC either.

My article of choice that boils MVC down to only the essential parts is From Flat PHP to Symfony2. The second half of the article starts introducing Symfony components, and you can skip that if you want, but the first half of the article is straight PHP and takes you step by step.

Fretburner explained this really well, but I had already typed this up, so here’s pretty much the same info again. :slight_smile:

This is mostly about separating concerns to keep each piece flexible and small in scope. For example, ideally the model doesn’t know anything about HTTP. Ideally it would handle the business logic without knowing or caring how the user is interacting with the application. If we did our job right, then we could also use all the model classes to make a command line application if we wanted to.

And the view is important to keep separated out also for flexibility, so that you can have multiple visual representations of the same data; and also to stay small in scope, so that the view doesn’t need to know or care where the data came from that it’s rendering. Maybe the data came from the database, or maybe the data was assembled on the fly for a preview, or maybe the data is mock data for development and testing. The view doesn’t know and doesn’t care, and that separate of concern helps keep it flexible and small in scope.

5

Well PHP MVC does have problems, but I definitely dont think it’s an overkill. The idea is separation of concerns/responsibilities, a view is supposed to be a view, it should not handle complex controller/application logic.

6

I worked with multiple teams on MVC structure. I do agree with the concept of being able to just jump into a project without trying to understand what the other developer did; but i couldn’t tell you how many times i jumped into a project using CodeIgnitor, Yii, zend or any other framework and it was just a disaster. Its up to the programmers to follow the MVC structure if they don’t then what’s the point.

When building my own MVC i found a router i liked that was easy to integrate into the Controller called AltoRouter. To me just seems like another way of doing URL Rewrite without getting into the HTACCESS file lol. I’m bit old fashion so i’m trying to get adjust my programming style.

My article of choice that boils MVC down to only the essential parts is From Flat PHP to Symfony2. The second half of the article starts introducing Symfony components, and you can skip that if you want, but the first half of the article is straight PHP and takes you step by step.

I heard alot about Symphony2 and Slim I’ll have to check them out.

The model layer is the core of your app, it encompasses all the logic for doing whatever it is your app is designed to do, but importantly it doesn’t know about where the input comes from or how to display output.

I agree. When i develop applications i normally call ‘models’ (app).class.php any business logic is in the class file. whether its GeoTracking, API Call through a specific vendor, or whatever. Then i can re-use those for any other project.