You down with MVC? Yeah you know me!

So on the way into work today for some unknown reason I was thinking about MVC design…

Note: For those readers of you that don’t know, MVC in this context stands for Model/View/Controller, and is basically a very popular framework design pattern for software development right now.

The basic idea in one variation or another is:

Model - relates to your data structure; most normally this means your database and your database structure, but sometimes it also refers to things like XML files, flat files, and other data stores. In very general terms you are supposed to store your data related logic and structure in these files.

View - relates to your user interface; most normally this means your graphical user interface (ie. in web applications it’s the HTML/Javascript that is eventually presented to the user). In very general terms you are supposed to store just the things that will be rendered to the user in these files (ie. just HTML/Javascript)

Controller - relates to the in-between glue; In very general terms you put all the code here to tie your data to your view.

With that (very) basic structure defined now, you might be thinking “OK sounds good and logical and all, but where does all my business logic code go?”.

Good question - lots of people seem to debate this as some favor shoving as much as you can into the models, and some favor shoving as much as you can into the controllers…but here’s the thing, they are both wrong!

What nobody who talks about these things seems to tell you is that all your business logic should be in it’s own classes (or files if you aren’t doing an object based approach).

Your controller should really be the glue that pulls not only your models and your views together, but also your business logic classes. Sure there will be some logic that goes into controller (just like there is inevitably some logic that goes into your models and your views) – it is after all still programming.

But the basic idea is to move your specific tasks out to their own classes/files…this way your MVC project can use them AND any thing else you ever do can use them (the whole benefit/idea of classes and reusable code)!

For example, if you have a class that handles all the fight action for something like BotFu fight I can easily plug that into my web based MVC application…and I can easily write another program that is scheduled to run as an automated bot who uses the same class to participate in fights…and I can easily write another program that listens for incoming emails and performs appropriate fight commands…

I think you get the point, with proper design and thinking, you can write one class that has your real business logic and then simply use different types of glue to stick that class into various other actions…

MVC is just one of those ‘actions’.

Anyway - thinking about all of this got me to think about lots of other things 'they never tell you’ about coding and development…and that got me thinking it might make for a pretty good book (or at least some nice rambling blog posts like this one)…what do you think?

This post has received 40 loves.


ARCHIVE OF POSTS



This is the personal blog of Kevin Marshall (a.k.a Falicon) where he often digs into side projects he's working on for digdownlabs.com and other random thoughts he's got on his mind.

Kevin has a day job as CTO of Veritonic and is spending nights & weekends hacking on Share Game Tape. You can also check out some of his open source code on GitHub or connect with him on Twitter @falicon or via email at kevin at falicon.com.

If you have comments, thoughts, or want to respond to something you see here I would encourage you to respond via a post on your own blog (and then let me know about the link via one of the routes mentioned above).