Yet another MVC Design

Everyone says ‘sweet’! As I basically am bringing up a topic that has been discussed a lot on this forum based upon my searches into the past.

I am currently looking to take my PHP programming to the next level. I have built a lot of tools for the company I work for. The software I have written has allowed me to tie together many aspects of the company into one interface. This interface keeps expanding by leaps and bounds. I’m thinking it is about time to start looking for a more long term design pattern for the next version.

I have run into several problems when reading about the different MVC based design patterns. For one, most are mostly focused on PHP and outputting to HTML. This is practical for a basic design.

The practical design would work for me if my application stayed within the realms of PHP and HTML. I say that, because I make heavy use of JavaScript, often writing a rather large amount of my application in it, and just using PHP to work with the many different databases.

So, having explained my dilemma, I am going to propose my idea of a folder structure for my design pattern. Here it is:

  • application
  • config
  • libraries
  • public
  • tmp

There are two things which most people would notice different about it and one would be the javascript folder inside the application folder. My reasoning behind this is just as I would usually have multiple views for one page, so I would also have different javascript for each view.

Also, in the libraries folder, I made a php and javascript folder. My reasoning behind this is because I will have base classes for both php and javascript (i.e. jQuery in some cases).

I am hoping for some advice from those who have much experience in application design patterns. What are foreseeable problems here? What would you do or wouldn’t do and why?

Any and all advice would be appreciated.

You say you rely heavily on JS, is that because you have some control over the choice of browser your users use?

Is it the case that you use Ajax heavily, and that some data goes directly from the view to the model, or that you feel it could do so?

Is there a feature of your existing business solution which is not well served by any of the existing frameworks?

Yes, due to this being an internal website the browsers available is restricted. Most of my code works in almost all browsers except IE 6.

Yes, my current design relies heavily on Ajax. But I’m thinking that no matter what I do, all information must be processed through a controller for validation reasons.

About the only framework that would be capable of supporting all of my features would be Zend Framework. But the learning curve for it is massive, and considering I already have most of the core application already built, it seems more feasible to turn this into it’s own MVC, rather than rewriting it into a Zend Framework dependency.

Then you could be targetting html5-ready devices, with its more advanced client side validation and form elements.

I wonder how much of what you mean by “validate” is actually “escape in order to protect your database” - discard that and use prepared statements - then perhaps see how much of what remains actually applies your business rules.

Are you effectively saying that the majority of your “framework” (as you have it so far) is to support an intranet or extranet, and that this solution you seek is to satisfy these users.

If some data is extracted and shown as your website, or exposed as data APIs - that is/will be another issue/team?

That is one of my intentions.

I use PDO, so I am using prepared statements. I will keep this in mind.

Yes. This is to support an intranet, and eventually an extranet version of it.

Nope. I am currently the only developer on this project.

I keep my js files outside of the web folder mostly so they can be under source control. I do this for css and images as well. Seems to work okay.

If you haven’t already you might want to glance the documentation on the Assetic Asset Manager which focuses on this sort of stuff. Might have a few ideas for you.

I watched the rise of MVC frameworks’ use in PHP (Mojave anyone?).

I used CodeIgnitor on a couple of projects - it was simple enough and worked fine.

I did not really understand MVC until I read Fowlers treatise on layers and n-tier in POEAA.

I understood one of the great attractions of using an MVC framework was that you would have to only edit one or two “layers” if you for example had to add a field to a form and a database.

Given that the backend of a CMS I work on is largely a front end to a CRUD operation and I wanted it highly Ajax (read 99%) controlled - I was dissatisfied with traditional MVC routing etc.

I later learned that what I actually wanted (and created) was named a SPA (Single Page Application) or to be more accurate consisted of a number of SPAs.

Have a read of this, again from Fowler, PresentationModel and maybe mock it up in PHP and see if that proffers any ideas.

I took that idea together with a PHP/JS library called Xajax, and with some enhancements, basic tablegateway mappers driven from ini files wrapping PDO as ‘models’ ( more like just data handlers than true models ) and some auto form generation helpers and made myself a crude PresentaionModel which as Fowler says “A view then simply projects the state of the presentation model onto the glass.”.

The great thing about it is that you can maintain extremely complex state quite easily - as hinted at in the example that Fowler gives.

The other good thing is that I do most work in one single file, which is in effect a very fat controller.

Naturally there are drawbacks, a very fat controller for one, the inconsistent and piecemeal way I have built up each controller for another.

The Xajax project seems to be grinding to a halt.

Finally my point.

I am dissatisfied with what I now have largely because I suspect that features of HTML5 and client side storage options (perhaps targeting a single browser platform in the case of Web Admin Backends) along with eyeing a parallel mobile platform, will :

a) provide an even better GUI experience
b) be easier to develop for

… and by taking on these challenges I don’t think looking immediately for an MVC solution should necessarily be taken as a given.