Bit of a workflow question.
I’m just staring with MVC and wondered how other people usually work in MVC? The 2 options I see is to code the model and controller completely first and then work on the views after. The other option is to code all parts at the same time.
I’m looking for what might be the quickest most efficient way to code in MVC? We don’t have inhouse designers or designated jobs so everyone does the same tasks (coding, designing, testing, db, etc).
Thanks!
1
There’s a third option, start by writing your tests. It’s the better option, and it’s not specific to MVC. If you do start by writing tests, then the next step depends on your approach to MVC:
-
Fat controllers / skinny models
Your controllers do all the heavy lifting, while your models are essentially POPOs, tasked with maintaining state between requests.
-
Skinny controllers / fat models
Your controllers are limited to passing stuff around, most (if not all) of your business logic lives in your models.
CodeIgniter favours the first approach but it doesn’t restrict you from the latter one. It’s completely up to you which one you’ll follow, personally I’d strongly suggest the second approach, simply because with fat models you’ll get the chance to test your business logic very early in the development cycle.
With skinny models, you’ll have to build both your controllers and your models before you’ll be able to test your business logic, and that’s not particularly efficient. Your business logic is the more important part of your application, I think it’s obvious that the sooner you build and test it, the better.
To summarize, my workflow is:
- Write the business logic tests,
- Write the models that would satisfy those tests,
- Pretend I practice TDD for everything else,
- Write the controllers and views.
Further reading:
- The M in MVC: Why Models are Misunderstood and Unappreciated
- Building a Domain Model – An Introduction to Persistence Agnosticism
- Preventing Code Rot 101: Unit Testing
-
Work in the controller – get things working – then push the methods to the model, then refactor in the model, then push to more then one model if necessary.
-
Most of the CI experts I’ve read recommended ‘skinny’ model. another reason to do this is the idea of pushing the specific implementation details down. The controller should be as abstract as possible.
For example to do a form a validation – the controller says – ‘validate this form’ It does not need to know anything about the form. So then when your form changes, you go straight to the model that works with it. -
One way to design is for the specific user role – Editor, Admin, Purchaser, etc – the person who is using the application at that moment. So then if you discover your classes are serving very different users (or use cases) – that’s a sign they could be difficult to change in the future.
-
DRY is useless if a new developer can’t read the code and understand what is going on. keep things simple and avoid the temptation to mash everything together in one method just because you can. (it updates! it inserts! it slices! it dices! its a maintenance nightmare!)
-
Learning Object oriented programming is not language dependent. Some of the best books and tutorials on OOP are in Java. Does not matter because the basic concepts are very similar. It’s also not a hot new thing where you have to get the latest book – there are great OOP books that were written a few years ago.