So another weekend passes by. I didn’t do any coding this weekend as I was assisting my dad with installing some poles for a shade sale that we are putting up in the front lawn to give some protection to the cars.
It has been a while since I did some heavy lifting and manual labour, but it feels good. You can stand back and enjoy what you have built.
But there has been one thing bothering me this weekend. Friday afternoon, one of my colleagues put in an email a discussion of how we are currently tackling software problems.
In one short sentence, stated that MVC and OO design principals do not work together. I thought for a second: “I’m writing objects, I’m keeping logic separate. I am making them work together, what is she on about”. Moments later and a little more reading (and thinking back to Uni days): “MVC keeps business logic away from the business objects. OO is meant to have methods that modify the model close to the model. We are all taught that a Bird object should be able to fly (OO). You don’t pass a Bird thing to a Bird controller telling it to ‘make it fly’ (MVC)”.
Quite honestly, I’m a little lost. You can’t change your whole approach mid-project (especially when you are half way through and have 2 weeks to go), but what am I going to do after it?
Where do I begin?
It almost feels like everything I have learnt has just flushed out the ears…
Somewhere I am hearing “What works for one project may not work for the next” :D
-= Comments
1. Matthew Delves | June 18th, 2007 at 7:52 am
From my limited understanding of MVC, you would have a bird that knows how to fly, it is then the controller that tells the bird where to fly to.
Hope this helps.
2. Xavier Shay | June 18th, 2007 at 2:22 pm
Controllers are responsible for the “flow” of the application. In web based apps, 90% of controllers either just render something, or save a model then redirect based on the result (success/failure). Controllers are glue, and you want as little of it as possible.
(In the rails world, this concept is often referred to as skinny controller/fat model)
3. Xavier Shay | June 18th, 2007 at 2:24 pm
… and remember, you generally want one model per view/controller action, so if you need a composite form or something, look into the Presenter pattern.
4. Zooba | June 18th, 2007 at 7:25 pm
I agree with Matthew, that’s how I understand it as well. At least in OO terms.
If you apply MVC to a RDBMS your business logic is kept in the controller with the data/information kept in the entities/tables.
The issue here seems to be the divide between what is the controller’s responsibility and what is the object’s responsibility. IMHO, the entity should have entity logic while it is the controller that has business logic. To carry on with the previous example, a Bird knows how to fly, but the controller knows (and tells the Bird) when and where to fly.
5. Xavier Shay | June 19th, 2007 at 2:00 pm
No way … what is the point of having a Model layer if your model is just … data? A PurchaseOrder should encapsulate the “business logic ” of what happens when it gets paid for.
I don’t like the bird example … you don’t model a bird in software and it doesn’t map to real systems.
