In my recent post regarding the Model Service layer, there was one query about me mentioning that the View is configured by the Controller which goes against the grain of traditional MVC idea of “Views Should handle their own Models / data”.
There is nothing wrong with Views being able to handle their own models, I’m not suggesting that this shouldn’t be the case. You can also do it this way. That is the “traditional MVC” way of doing things and it works fine which is why I’m questioning why I’ve moved away from it. I’m just typing as I go so hopefully by the end of it, we’ll have something that makes a point.
I used to trumpet the sh*t out of this because I had it figured out and it made me feel smart 
. I thought hey, I can adhere to the traditional MVC way of things and make the View select it’s own Model (or models) and gather information on it’s own – all I need is a View Helper. Further along came the question “What about the times when the Model needs to be used by the Controller?” well I got a plan for this too, then there’s the “What about when the Controller and View need access to the same model?” case. I needed to create a strategy to make sure that the Model isn’t instantiated twice in these cases.
» Read more: Is it important that Views pull data from Models on their own?
The Model Layer of the MVC triad: I’ve been thinking this over for the past few months since using the Doctrine ORM and I think I’ve finally made some progress to get this issue licked. In the past, I’ve agonised over this issue and blogged about my progress. Some weeks or days later I tried to probe the community on what they would do, Now I think I’d have an idea on what I would do.
After some more thought and lots of research on the subject, I’ve come to a solid point where I actually have something to try out which seems semantic aside from the naming of the class (Service Class) – but this is derived from what some people are talking about in ZF circles starting from Matthew Weier O’Phinney who was coining it as the “Gateway to the Domain” from early on, then later changing it to “Service Class”.
» Read more: My Zend Framework Model Layer: Part Service, Part ORM
Last week I received a phone call of distress from one of our clients. The were asking for some advice regarding issues they were having with a Web Application that was developed for them by another company and was released into production the week before. Now I’m not going to name names, or even mention what Web Technology was used – this is not what this rant is about.
The plea for help was pre-empted with a light-hearted exchange between the Client and I where the client jokingly blamed me for the predicament that they were currently in.
“You said late last year that you had a full schedule and that you were not taking on any new projects until February (resulting in them hiring these guys) [...] so it’s your fault!”
I know the Client very well and they are very reliant upon the technical consultants that they hire to provide direction and complete the project as they have no technical expertise themselves or technical staff internally. This Client needs to be taken good care of (of course, as do all clients) since they put total trust into the technical consultants that they hire and have no real input into the direction of the development aside from the business rules.
The problem is, with the exception of the Web Development company I work for, it seems as though they keep picking the wrong Web Development companies when they are not with us.
From what I hear, the web development companies they hire are full of hype and seem to be stepping into the projects without covering the usual bases. Now, for a company whose average project consists of Mission Critical Web Applications as opposed to your run of the mill Joomla CMS, Sugar CRMs or E-Commerce websites, this is very dangerous.
» Read more: Client Gets Screwed by Under skilled and disorganised Developers
Most of my day was spent on developing the User Model Layer for an application that my team and I are currently developing at DevProducts HQ. I’d like to briefly talk about how we are using TDD and discuss one major benefit that this method of development provides for my team and I during development.
While TDD has many benefits, my favourite is that it helps to keep me and the other developers on my team focussed on the components we have chosen to work on. Not only that, but it helps us focus on the task at hand as it forces us to think about each unit of the component and write it so that it _can_ be tested – as much as I’d like to expand on TDD itself, for this post, I’m just going to explain how it could help you keep focussed.
» Read more: Unit Testing & TDD Keeps you focussed and gives you Peace of mind
Ben Rowe (8)
Bill Karwin (6)
Kevin (6)
James Horne (5)
Martin (4)
Walter (4)
David Penner (3)
Loïc Frering (3)
Mic (3)
San (3)