Monday 21 May 2012

Roadblock - MVC

MVC seems good in theory, but what about in practice?

Well... I have become stuck already. I have been investigating the principles of MVC and tried to create a simple 2 page website, but I have become stuck at the point of splitting up the separate components.
One of the things that has made me scratch my head most is that many people insist on a single entry point when building an MVC framework. I am currently awaiting a response to my comment on stackoverflow to see why this is a good idea. To me it seems very insensible for several reasons (I have not looked into these reasons too much so I could be wrong):
  1. Passing information through the URL doesn't seem very human friendly.
  2. It depends on how the MVC framework works as to how the parameters are used to fetch a page which could make debugging harder for an outside developer.
  3. Can Google Analytics deal with a single entry point?
It feels like this approach may be more suited for some sort of Javascript type single page that works more like a program (or web app) than web pages. Does anyone have any decent examples of websites with single entry points?

I get the feeling that I am taking the phrase "single entry point" too literally. Perhaps the point of a single entry point is to set everything up in a unified way (database connections, security, page headers and footers etc...)

Going back to MVC rather than single entry points, I can't find any explanation as to whether each page needs all the components.

For example, many websites revolve around adding, editing or removing data using forms. To process forms using PHP requires POSTing the data to a PHP page.
With the current framework I use, the forms mainly POST to the page they're on and check the $_POST superglobal to see if the form has been submitted, if it has, the page processes the form, if not, it displays the form. To me, this approach seems silly, to mix processing and display. And also causes problems when refreshing.
With the framework I used at my old company, all form processing was split over three pages. The form page, a processing page, and a success page. This seems a lot more logical way to process forms using PHP, but in this case, the process page would not need a display component as it mearly processes data. Which is why I'd like to know if M,V and C are required for all pages.

I have made a tiny example 3 page website. Which you can download the zip for.
Each page is based on a viewController class which has a view passed to it. The view extends the model. There are base classes which should be generic and then classes that extend those specifically for the 'testytest' example site. I'd like to challenge someone to recreate this 3 page site in their neater, own MVC way and send it to me.
It seems a bit of overkill to have so many files. Another question I have is, does the M,V and C have to be explicitly separate? or can they all exist separately in the same class?

I find 'helper functions' useful. I think these might be classed more as library functions than part of a Framework. Should these be included in the Framework? or should they be in a separate 'library' folder?

Sorry if this post is a bit of a mess. I was just trying to get all my ideas down. I'll try and tidy it up later.

Please comment with your ideas, input, suggestions and articles regarding any of the concepts mentioned in this post.

No comments:

Post a Comment