Mommy VVants Candy (MVC)

Time to do some architectural decisions. I guess they call it designing - so here we go, let's talk about the design. I do not usually go for the newest and the fanciest, because it is usually immature and just gives you more problems than you can handle. Besides, most of the time it brings you way too much to learn. I've got plenty of learning to do with PHP alone! I've never done anything with PHP before. What comes to the new and fancy, I won't be doing much of it here, either. Architechure-wise, let's go with the trustworthy Model-View-Controller (MVC) design pattern!

Using a commonly known pattern helps others to get aquainted with your code. Basically, you don't need to document everything in such detail either. Patterns are all based on common designs, so you can reference to existing pattern documentation. Also, patterns are widely used in the industry and they have been proven to work in about a billion applications.

My Model (the "M")

I have drafted a simple data model for the first sprint of my development. You can find more information about data models here. For drawing up the actual data models, I've found UMLet to be a light but sufficient tool. My data model is a conceptual schema containing a little bit of this and that, but I did go into some detail with one entity: the player. I was thinking to take my first plunge into the world of PHP by implementing a few simple modules: player management, registration and sign-in. Implementing these would force me to get to know a variety of different aspects of PHP such as database interaction and session management in addition to standard PHP syntax. So I need to implement one or more database tables to store basic data. Most importantly, I need to implement a value object/bean class, which contains the player data. This is the interface, which separates the model from the view and the controller. The view and the controller do not need to know how the model is actually implemented, they just know how to access it. Also, I will need a mechanism for the value object to persist itself into the database. But that's another pattern and I'll save it for another day.

My View (the "V")

I would just so much love to say that the view is the simplest to implement out of these three. Unfortunately today's (Internet) users are completely spoiled with all kinds of Web2.0, ajax-based and pimpedy-more-than-pimped GUIs. It's the era of true web applications. Forms and pages ain't just enough. So, a lot of sugar coating with hopefully reasonable amount of non-choking Javascript code. All smooth and without noticable lag. Muah-hah.. a wet dream. Seriously, user interfaces are getting more and more complex and unfortunately the separation between the view and the controller is getting somewhat dimmed mayhaps due to such extensive use of Ajax. Especially, if you're not careful with you Ajax dosage. But I'll try to be. Anyway, for the view, we most probably need some kind of tiling mechanism. Most probably we will be using ajax calls in order to minimize payloads (and thus loading times). But that's another subject for another blog entry. Right now what's important is to separate the view from both the controller and the model. I'll need some "views", "pages" or "screens" for e.g. browsing and managing users etc. There are always a few of those naughty ones out there, who needs to be put on hold (i.e. ban) for some time!

My Controller (the "C")

The controller is in charge of taking care of incoming requests. Usually, the controller is separated into two parts: the front controller and a bunch of page controllers. The front controller checks what this request is all about and forwards it to an appropriate page controller. Since we're going to implement some functionality regarding player management, it would be logical to implement a separate page controller for player management and then separate controllers for other "modules". But I still need to check how this front+page controller pattern fits in with PHP. Mebbe yes, mebbe no - I don't know yet. Anyway, the controller uses the model to manipulate data and passes manipulated data to the view, which in turn shows it to the players.

Let the discussion continue in the forum!