Page 1 of 3

Minimalistic MVC Framework

Posted: Wed Oct 22, 2008 10:56 am
by volomike
This one was just too good. I had to repost from Reddit to here:

http://www.terminally-incoherent.com/bl ... rk-in-php/

Re: Minimalistic MVC Framework

Posted: Wed Oct 22, 2008 12:01 pm
by Christopher
Nice. The next step is to make most things optional, rather than hard coded. And then on to full-stack! ;)

Re: Minimalistic MVC Framework

Posted: Wed Oct 22, 2008 12:37 pm
by volomike
Yeah, I'm not a tremendous fan of MVC stuff. I just don't see the point. But if a client wants me to use it, and there's no getting out of it, then I'll be sure to go with this thin one. (BTW, I highlighted the text, pasted it into OpenOffice, and clicked the PDF button so that I could make a PDF of this for later reading when I need to use it.)

For MVC, you see the controller is just a thing that gets passed input, runs it through various model stuff, and then pushes to the output in the view. Therein lies some problems. First, the way many MVC engines work, the URLs aren't very SEO friendly, and that's important these days. Second, there's no rule on when to make another controller, so you end up seeing some really fat controllers, which becomes like spaghetti code -- the thing you were trying to avoid with MVC. Next, it gets away from the simple nature of having a separate page per kind of task, such as contact.php for your contact form and form processing.

So if you take away the controller, you then are left with model and view. Model is just a way to load class modules for reusable code. Okay, why not just load your class modules for reusable code? Why the formality of a model?

So then you're left with View. View makes a whole lot of sense to me, so I use it. That's why I came up with CCAPS.

So, for me, I now use Apache2 mod_rewrite very heavily so that I get friendly SEO-optimized URLs, I have my "controllers" as separate PHP pages, I use strict formatting of my PHP pages so that code goes into neat little commented slots in a consistent manner, my "model" is just a "classes" subfolder with classes inside, and my "view" is CCAPS.

Therefore, to me, MVC is just a fad.

Re: Minimalistic MVC Framework

Posted: Wed Oct 22, 2008 2:08 pm
by Christopher
volomike wrote:Therefore, to me, MVC is just a fad.
If you are serious about that statement then you are claiming to know a lot more that many smart people ... plus it has been a very long fad! ;)

Honestly, I think at some point you will probably see the benefits of using a Front Controller rather that the Page Controllers you currently use.

Re: Minimalistic MVC Framework

Posted: Wed Oct 22, 2008 5:41 pm
by alex.barylski
volomike wrote:I just don't see the point.
Clear and preferably clean separations of concerns. It's logical layering. When you have View code mashed in with your model code, you really start to have problems. That is probably the most important separation IMHO.

Most developers agree that using templates simplifies their code...well MVC takes it a step further. Each of those layers can further be sub-divided and so on. The more layers you have, the more difficult your code is to step through when first learning MVC but once you have a grasp of where all functionality goes it saves tremendous time in finding faulty code. Isolation is another benefit. Have someone work strictly on a model any nothing more. Lets me as a single developer stay more focused.
For MVC, you see the controller is just a thing that gets passed input, runs it through various model stuff, and then pushes to the output in the view
In passive view it usually pushes but there are instances where the model might need to pull data in directly. A controller is usually a pretty basic component, it handles application logic. Depending on how sophisticated your application is, that will dictate your controller complexity. Most web applications are complex but they are not sophisticated.
Therein lies some problems. First, the way many MVC engines work, the URLs aren't very SEO friendly, and that's important these days
Mine uses clean URL's with the simple addition of an .htaccess file. Granted I couldnt' easily switch to a index.php?ctrl=do&action=something now with out editing every template but that is OK cause it's a hosted application.
econd, there's no rule on when to make another controller, so you end up seeing some really fat controllers, which becomes like spaghetti code -- the thing you were trying to avoid with MVC.
There is no rule in using GLOBAL's either...so what? MVC promotes goo practice most do not dictate -- which is a good thing. My controller are all less than 50 lines of SLOC.
Next, it gets away from the simple nature of having a separate page per kind of task, such as contact.php for your contact form and form processing.
I'm not sure I understand.
So if you take away the controller, you then are left with model and view. Model is just a way to load class modules for reusable code. Okay, why not just load your class modules for reusable code? Why the formality of a model?
Modularity and clean separation.
So then you're left with View. View makes a whole lot of sense to me, so I use it. That's why I came up with CCAPS.
Arguably (In my experience) that is not a 'view' so much as a template layer which in my case sites under the view or is used by the view.
I have my "controllers" as separate PHP pages,
Sounds as though you are almost MVC -- page controller approach as opposed to front controller. I hated that approach so I always favoured using a snigle index.php to essentially act as the front controller, which was one giant hard coded switch statement. Each CASE would accept the REQUEST data, pass it to a model (data access layer) and take that result and pass it to a template layer like Smarty templates or whatever.

That is basically achieving the same effect, only far more tightly coupled and the separations are not as clean. You also lose a lot of flexibility in the architecture of your application. But it reads easy. Everyone knows to start with index.php when your stepping through a application.

The problem with the above approach is it's very hard to keep the index.php clean when you start getting past a few thousand lines of code. You start having includes and external scripts (like ajax.php, login.php, logout.php, etc) and each of those external scripts might potentially open up a security hole because you forget some check, so you try and centralize all common logic using a master include. While this works for a while, becuase it contains security code you need to include it every file, even when many do not need the additional functionality, so now your application is wasting cycles parsing code it won't execute.

Weird bugs start to creep in, because of headers() you set in some deeply nested include, which are appropriate for for some action, so now you must struggle to find what the heck is going on by sifting through 20 includes. When you finally find the bug and realize a the mistake and apply a fix by moving the header() into another file of it's own...you later stumble into ANOHER bug because some scripts didn't include this essentialy header() code.

The list goes on and on. MVC assists in solving these issues. Remember, MVC was an innovation of people who have probably been there and done that. The problem with MVC is it's frequently so under or over explained. Fowler, Java Blue Prints, MS Patterns Repo all do great job explaining MVC and page controller over front controller but you will never understand it on first read. They are intended for people using a framework who just want a general over view of what happens, not for someone wanting to implement MVC themselves.

MVC is both simple and complex. The basic principles are trivial but knowing exactly what goes where and why and when is the most difficult riddle to solve as a developer. Does validation go in the model? Some would yes (I did) now I say no...
Therefore, to me, MVC is just a fad.
Define fad? :P Will there be a better way? Nope. Not conceptually anyways. In software when you do something right it just works. In my experience what improves about MVC is the amount of separation and logical organizing you can easily achieve after your application fully uses MVC. All the individual layers which make up the MVC components.

Cheers,
Alex

Re: Minimalistic MVC Framework

Posted: Thu Oct 23, 2008 12:02 pm
by josh
volomike wrote: the URLs aren't very SEO friendly
MVC has nothing to do with URLs. At all. If you wanted you could use apache rewrites instead of a front controller but you'd still be following MVC. Is it really the pattern you don't like or the term?
volomike wrote: Model is just a way to load class modules for reusable code. Okay, why not just load your class modules for reusable code? Why the formality of a model?
Call it what you want, its still the same thing.
volomike wrote: my "model" is just a "classes" subfolder with classes inside, and my "view" is CCAPS.
Therefore, to me, MVC is just a fad.
Sounds like you're already following MVC then, with the exception of duplicating your model use cases. ( or if you want to call them "reusable class modules" )
PCSpectra wrote:Mine uses clean URL's with the simple addition of an .htaccess file. Granted I couldnt' easily switch to a index.php?ctrl=do&action=something now with out editing every template but that is OK cause it's a hosted application.
At least with zends implementation if you really wanted to you could simulate an "un" SEO friendly URL route scheme. ( just by updating your routes )

Volomike, not trying to offend you but you but from your explanation you are terribly misunderstanding MVC. I know because I was you 3 months ago.

Will there be a better way? Nope. Not conceptually anyways.
and the earth is flat.

Re: Minimalistic MVC Framework

Posted: Thu Oct 23, 2008 3:52 pm
by alex.barylski
At least with zends implementation if you really wanted to you could simulate an "un" SEO friendly URL route scheme. ( just by updating your routes )
I can easily accomplish the same thing via a plugin in my front controller...but you still have to echo the URI inside your templates don't you?

Code: Select all

<a href="?index.php=ctrl=user&action=edit&pkid=5">Edit</a>
or

Code: Select all

<a href="/user/edit/5">Delete</a>
That is the "problem" I was trying to describe. Unless you use a template helper to construct the URI's and the helper has knowledge of the type of URI you wish to construct you would still need to update all your template files, redirects, etc. Wouldn't you?

Re: Minimalistic MVC Framework

Posted: Thu Oct 23, 2008 5:10 pm
by Christopher
PCSpectra wrote:That is the "problem" I was trying to describe. Unless you use a template helper to construct the URI's and the helper has knowledge of the type of URI you wish to construct you would still need to update all your template files, redirects, etc. Wouldn't you?
Unless the FC will accept either type of URL.

Re: Minimalistic MVC Framework

Posted: Thu Oct 23, 2008 6:12 pm
by alex.barylski
Unless the FC will accept either type of URL.
OK I see what jshpro was saying now, however regardless of the routes your FC understands, if your templates echo dynamic URL's they are essentially SEO unfriendly, no?

No amount of switching the FC routes will fix the URI's used by your application in that sense. I suppose supporting multiple routes does make it easier to port an applicaiton over from dynamic URI's to static URI's by supporting both at the front controller.

Heh...I'm confused now as to what my original point was. :lol:

Cheers,
Alex

Re: Minimalistic MVC Framework

Posted: Thu Oct 23, 2008 7:40 pm
by josh
PCSpectra wrote: if your templates echo dynamic URL's they are essentially SEO unfriendly, no?
First of all I was just saying as long as you don't put an "id" attribute in your GET string search engines will treat your URLs the same, aside from any keywords occuring in the URL.

Secondly the method of generating the URL has nothing to do with the search engine friendleness of it, What makes a URL SEO friendly is containing keywords essentially, or possibly eliminating the get string at the end of the URL, either way use or non use of MVC doesn't change this, use of a MVC url generating view helper and routing framework only changes the ease of updating the URL scheme, incase you need to redefine what SEO friendly means later

Re: Minimalistic MVC Framework

Posted: Fri Oct 24, 2008 11:14 am
by volomike
Okay, guys, but can my URL look like the following in an MVC framework?

http://mysite.com/articles/wealth-management/general/how-to-start-building-wealth

Of the MVC URLs I've seen, I haven't seen them look this smooth.

So would I be feeding the stuff in bold to index.php to the controller code in there, or would I be feeding it to articles.php to the controller in there?

If passing to index.php, then I can see that becoming one monstrously big controller file, if, say, this were a website that offered up a lot of features. And if broke out into separate controller files, then I don't see the point of using a controller when you could just parse the incoming URL and go to town operating on the application logic, right away. If there are separation of concerns, then great, even without an official MVC platform, one could just use other techniques to separate their SQL from their HTML from their application logic.

So, for me, my controller isn't named a controller, but it does the same thing. It routes logic to the appropriate processing area, but it's just another page. Then, my model isn't named model -- it's just a series of classes stuck in /classes. I throw in a custom-made ORM (similar to Outlet ORM but even thinner) and I abstract my SQL out. For the view, I don't call it a view -- I call it a template. And I use CCAPS to finish out the view logic. Piece of cake. No tremendous learning curve. And it runs much faster than any MVC framework I've seen because it has less layers of goo to get through. Reading my source is very clean. I mean, my "controller" logic is always laid out the same, page to page. I start with a commented template file with slots for where I need to stick stuff. So, newbies who view my code no exactly where I'm going to do something. And all my database calls either go directly through a specific "model" class, or through the ORM, or directly through my abstracted DB class, depending on need (and my time available to do something).

I mean, I've done the MVC thing for a bit. Worked with Zend. Got my secret decoder ring and a T shirt. Went woo hoo. Learned from it. Saw it slow down dev time and running code time. Didn't see the point. Moved on to my own thing, just more polished from there on out because I learned from the MVC.

Rasmus Lerdorf, a Yahoo employee who is one of the main contributors to the PHP language, has been a key influence on my thinking. Here's his views on the MVC:

http://toys.lerdorf.com/archives/38-The ... ework.html

And his benchmark tests against many popular MVC frameworks have shown that using these frameworks can slow down any project's running speed significantly. He is influenced by Separation of Concerns (SoC), yes, but does not insist that one go the MVC framework route.

I've also seen him say, and I don't have the quote right in front of me, that when he wants to speed something up, he tries to rewrite it better in PHP. But when that fails to deliver significant results, he writes it in C and throws it into PHP as an extension. That was another interesting view, as well, for me.

Re: Minimalistic MVC Framework

Posted: Fri Oct 24, 2008 12:50 pm
by Christopher
volomike wrote:Okay, guys, but can my URL look like the following in an MVC framework?

http://mysite.com/articles/wealth-manag ... ing-wealth[/b]

Of the MVC URLs I've seen, I haven't seen them look this smooth.
Let's be clear, "smooth" is neither objective or a technical term. Just say you like your URLs that way -- in your opinion. I have been in too many ridiculous design discussions where you say that and another programmer says he hates that URL and that the only "smooth" way is
http://mysite.com/articles/general/wealth-management/how-to-start-building-wealth. Most of the difference in people's code is about little opinions like this.
volomike wrote:If passing to index.php, then I can see that becoming one monstrously big controller file, if, say, this were a website that offered up a lot of features. And if broke out into separate controller files, then I don't see the point of using a controller when you could just parse the incoming URL and go to town operating on the application logic, right away. If there are separation of concerns, then great, even without an official MVC platform, one could just use other techniques to separate their SQL from their HTML from their application logic.
Why does using a Front Controller create "one monstrously big controller file"? Is it all the custom routes? Because Front Controllers are really only trivially more lines than Page Controllers.
volomike wrote:So, for me, my controller isn't named a controller, but it does the same thing. It routes logic to the appropriate processing area, but it's just another page. Then, my model isn't named model -- it's just a series of classes stuck in /classes. I throw in a custom-made ORM (similar to Outlet ORM but even thinner) and I abstract my SQL out. For the view, I don't call it a view -- I call it a template. And I use CCAPS to finish out the view logic. Piece of cake. No tremendous learning curve.
You call everything by your own names and then claim no learning curve -- for you. For people who know things by their names it would probably be very confusing.
volomike wrote:And it runs much faster than any MVC framework I've seen because it has less layers of goo to get through. Reading my source is very clean. I mean, my "controller" logic is always laid out the same, page to page. I start with a commented template file with slots for where I need to stick stuff. So, newbies who view my code no exactly where I'm going to do something. And all my database calls either go directly through a specific "model" class, or through the ORM, or directly through my abstracted DB class, depending on need (and my time available to do something).
Of course you can always produce a faster system by building something custom for you own likes that is not general purpose. So you are just stating the obvious here.

Certainly Rasmus' design is valid given his priorities, but that does not that there are not other valid designs given other priorities. I doubt what Yahoo actually uses is what you saw posted -- the article was contrarian to get people to think about frameworks. I think in general that programmers move from insular systems like yours to more general systems because of the many other benefits.

Re: Minimalistic MVC Framework

Posted: Fri Oct 24, 2008 2:55 pm
by alex.barylski
So would I be feeding the stuff in bold to index.php to the controller code in there, or would I be feeding it to articles.php to the controller in there?
In my system eveything gets sent through index.php. This has nothing to do with using a front controller though. Your directories would be virtual and would probably just map to nested articles or folders system if implemented. MVC is usually touted as an application development framework, which is why you haven't seen "smooth" URL's. That URL is more likely found in a front end of a CMS or content delivery engine.

You can still use MVC (which I do) as the framework for such an engine.
If passing to index.php, then I can see that becoming one monstrously big controller file, if, say, this were a website that offered up a lot of features. And if broke out into separate controller files, then I don't see the point of using a controller when you could just parse the incoming URL and go to town operating on the application logic, right away. If there are separation of concerns, then great, even without an official MVC platform, one could just use other techniques to separate their SQL from their HTML from their application logic.
It would become a large index.php if you kept index.php hardcoded or static.

Code: Select all

$page = $_GET['page'];
switch($page){
  case 'about-us':
  {
    // TODO: Instantiate model and/or view
    echo 'Create your view or template for about-us';
    break;
  }
  case 'insurance-calculator':
  {
    // TODO: Instantiate model and/or view
    echo 'Create your view or template for calculator';
    break;
  }
  case 'index':
  default:
  {
    // TODO: Instantiate model and/or view
    echo 'Create your view or template for default landing page';
    break;
  }
}
Although some might argue this is not technically a front controller I see the concept as being very similar -- in that each CASE is a hardcoded action controller. What a front controller does do, is remove that hardcoded dependency by making each CASE a "module" or "action controller".

You can see the benefits to having a single index.php as athe application entry point, right? But you also see the switch growing to massive size. What the front controller does is something like:

Code: Select all

 
$page = $_GET['page'];
 
$html = execute("controllers/$page.php", $_REQUEST);
 
// TODO: Apply any filters to resulting HTML -- such as hyperlinking URL's or hilighting key words
echo $html;
 
 
Where execute might look something like:

Code: Select all

 
function execute($controller, $request)
{
  include($controller);  
  
  $controller_name = basename($controller, '.php');
 
  // TODO: Fetch $action from $_REQUEST
  $action = $_REQUEST['action'];
 
  $controller_object = new $controller_name();
  return $controller_object->$action($request);
}
 
And your action controllers might look like:

Code: Select all

 
class MyController{ 
  function doSomething($request)
  {
    // TODO: Create model and view and return results
    $smarty = new Smarty(); // Or CCAPS
 
    return $msarty->execute(); // Or whatever the rendering function is called
  }
}
 
Now you could use a front controller with a URI like:

index.php?ctrl=MyController&action=doSomething

Code: Select all

 
$ctrl = $_GET['ctrl']; // Get the controller name
 
$html = execute("controllers/$ctrl.php", $_REQUEST);
 
// TODO: Apply any filters to resulting HTML -- such as hyperlinking URL's or hilighting key words
echo $html;
 
This is a very crude example but should demonstrate the basics in how a front controller prevents your index.php from growing into something nasty. Action controllers are simply PHP scripts/functions/classes/whatever that have their context set for them by a front controller, saving you from repeating your self.
So, for me, my controller isn't named a controller, but it does the same thing.
Probably the best thing patterns have done for me, is give me a common language to use. If you have been programming for any number of years, most patterns probably make sense and are even solutions you've applied in the past under your own monikers. Problem is what you call a module loader, someone else might call a kernel and someone else might refer to it as an engine, etc.

All these names are great but when I first enter a codebase I have no idea what any of those terms mean and while documentation helps, wouldn't it be best if the code described itself and allowed you to focus your commenting skills on code that really needed it?
Piece of cake. No tremendous learning curve
I could have a developer up to speed within a few days on my system, which is a fraction of the time I have experienced with every project I have ever worked on.
And it runs much faster than any MVC framework I've seen because it has less layers of goo to get through
While my system has many layers I would challenge any project to a benchmarking contest of equal size. In my experience, the extra layers serve to modularize your application, meaning only components which need executing actually get parsed. I estimate about a 2% parsing overhead of code that actually doesn't get executed, I would put most other applications I've worked on at 20-40%.

Zend has a lot of complexity. Even simple components like the request object are massive. Not all MVC frameworks are created equal.
Reading my source is very clean
Everyone thinks their source is really clean, that is what my last employer promised me too and it took 3 months to learn 50K lines in and out. You know what clean means to me?

1. Small, simple well named functions. Are any of your functions over 50 SLOC (not physical)? Not clean anymore.
2. Does your code ever use more than 2 levels of nesting? Whether it's an nested IF or WHILE? More than two equals code smell.
3. Are your variables ever acronymized? $arr $cnt $res? I consider that a code smell.
4. Do your comments consume more than 5% of your physical lines of code? Yes? That I consider a code smell.
5. Do any of your functions, classes, modules, files or folders has similar names? If you have more than one directory named 'core' that is a code smell.
6. Do you have *any* HTML anywhere outside of your templates? Even a simple boldify. I consider that a code smell.
7. Do you have anywhere, more than a dozen files in any one directory? I consider that a code smell.
8. Do you have any code duplication more than 4-5 lines? I consider that a code smell.

I could go on all day but I won't cause you get the point. Everyone has different standards and ideas as to what constitutes clean code. My biggest gripe with code is seeing response code in the index.php or template code in the controller or validation code in the data access layer, etc. My applications are extremely modular and I expect things to be where they make sense to me. The minute they don't I have to start learning a system.
I mean, I've done the MVC thing for a bit. Worked with Zend. Got my secret decoder ring and a T shirt. Went woo hoo. Learned from it. Saw it slow down dev time and running code time. Didn't see the point. Moved on to my own thing, just more polished from there on out because I learned from the MVC.
Where is my secret decoder ring? :P

So you admit you learned from MVC and polished your practice? What makes you think the learning has stopped? MVC will take a long time to fully understand, and in fact I'm not sure you ever stop learning. There are so many questions of what goes where and why you have to answer when you really think about it, and to complcate matters, sometimes code makes sense in the controller when other times it makes sense in the model. Depends on your particular architecture.
I've also seen him say, and I don't have the quote right in front of me, that when he wants to speed something up, he tries to rewrite it better in PHP. But when that fails to deliver significant results, he writes it in C and throws it into PHP as an extension. That was another interesting view, as well, for me.
Writing a function in C woudl certainly speed things up, yes...what does that have to do with MVC? :)

Re: Minimalistic MVC Framework

Posted: Fri Oct 24, 2008 7:13 pm
by josh
I think a simpler way of explaining how MVC relates to your URLs is, usually in the dispatching loop the first dispatched action is usually chosen by your programs invocation arguments. In our niche, web development that is the URL. Usually in an MVC framework you'd define routes which are kind of like rewrite rules for apache, but defined in the code. Your routes act as a lookup for your MVCs dispatcher to decompose a URL into a stack of actions the dispatcher loops through and invokes. You could definitely define the routes to let the MVC map URLs exactly like you posted, with content titles spelled out in the URL. Yes you are defeating the web servers functionality that already does this, but its only reinventing the wheel if you try to re-implement MVC. MVC has been implemented and the advantages are well documented.

You can call it MVC or you can call it "noun thingy class", "presentation thingy class", "user flow thingy", but don't confuse yourself... we're all talking about the same thing

Re: Minimalistic MVC Framework

Posted: Tue Oct 28, 2008 5:48 am
by panic!
You can make your URIs look however the hell you want with or without a framework.

How you obscure or organise your query strings has no indication of the quality of the framework and or code below.

I ****ing LOVE MVC.

I love how I can come into almost any MVC based php (or ruby or whatever...) application and know where everything is going to be.

If an application pattern (and MVC is the most widely used in the web-world) isn't used you are fully at the mercy and whim of however someone else 'feels' is the best way to organise and structure their application.