Explain MVC to me assuming that i am supremely thick!

Soldato
Joined
3 Apr 2003
Posts
2,928
Hey guys,

I have been programming for a while and despite this question I am actually fairly proficient in c++/c#/java. By fairly i mean i have finished my second year of uni on computer science and made some programs but if i am honest i still struggle to get my head around some concepts. I can code, but dont fully understand the code if that even makes sense.

Now i have decided to teach myself asp.net over the summer as i figure i would like to move towards web dev as a career, however when i read about things like MVC i just cant get my head around exactly what it means no matter how many explanations i have read. So apparently its separating the visual aspects, logic and data? But i still dont really understand the concept. How do you know if you are following MVC or not?

I dont even know if this question makes sense lol, its so hard for me to explain what i mean i just dont quite grasp these conventions.

So please can somebody explain MVC to me with some examples maybe that will help me to understand it better? Thankyou.
 

AJK

AJK

Associate
Joined
8 Sep 2009
Posts
1,722
Location
UK
... i have finished my second year of uni on computer science and made some programs but if i am honest i still struggle to get my head around some concepts. I can code, but dont fully understand the code if that even makes sense.

Don't mean to be rude, but this is a worrying statement. You've finished the second year of a CS degree but don't understand the code you're writing? Sounds like you need some academic support from your university.

Edit: the first result from Engram's suggested Google search should go a long way to explaining MVC, but to be honest if you're struggling with the more basic concepts of programming you might want to get those straight in your head first.
 
Soldato
Joined
17 Jul 2008
Posts
2,820
Location
London
VMC ideas as I understand and from experience of using it in real world situation:

Models contain your data, for example if you have a car dealership website database, your model would be cars where you might have functions such as getCarByReg(), getAllCars(), getCarByPrice()

Controller would be something that will call those model functions, so when a user wants to view a list of cars, you would handle that at the controller level. You would have your "action" functions there for example listAction, viewAction, searchAction

And view would simply contain your html templates into which you could insert what controller retrieves from the model.

Its a very rough overview and if you are using it for a simple application, there is 0 use in this really. You would spend longer setting up your framework to make use of it for little gain. Its main use is in larger projects. For example content management systems, where your models might be

cms_items, cms_users, cms_permissions, ect.
 
Associate
Joined
22 May 2013
Posts
1,229
Location
N. Ireland
I've been programing professionally now for four years and have to say that I learned more in my first 6 months of industry than I did in 4 years of uni. So with regards to your proficiency claims I would raise an eyebrow. None the less I've found Jeff Atwood's coding horror blog very good at explaining various parts of the .Net framework and how MVC should be used http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html another good resource is Scott Hanslemans blog, I'm not sure if he has any MVC posts but in general its very good reading for all things .Net
 
Soldato
OP
Joined
3 Apr 2003
Posts
2,928
VMC ideas as I understand and from experience of using it in real world situation:

Models contain your data, for example if you have a car dealership website database, your model would be cars where you might have functions such as getCarByReg(), getAllCars(), getCarByPrice()

Controller would be something that will call those model functions, so when a user wants to view a list of cars, you would handle that at the controller level. You would have your "action" functions there for example listAction, viewAction, searchAction

And view would simply contain your html templates into which you could insert what controller retrieves from the model.

Its a very rough overview and if you are using it for a simple application, there is 0 use in this really. You would spend longer setting up your framework to make use of it for little gain. Its main use is in larger projects. For example content management systems, where your models might be

cms_items, cms_users, cms_permissions, ect.

Cheers matey appreciate the effort.

I did google this beforehand but the explanations are all kind of abstract and its that part of it that i really dont understand. Does it mean seperate the functions into different files is it all just a conceptual thing and no bearing on the files i am creating etc.

As for worrying about my course, i worry about it myself. More worrying is the fact i am one of the stronger programmers in the year. The code comment i made in error, i understand my code, its the concepts i am having trouble with. I get OOP etc but when comes to things like MVC i am just not sure what it really is. Figured better off asking here whilst i try to get better over summer.

There is no academic help to be had as i am having no trouble doing my assignments, this is something i wish to work on in my own time.
 
Last edited:
Soldato
OP
Joined
3 Apr 2003
Posts
2,928
I've been programing professionally now for four years and have to say that I learned more in my first 6 months of industry than I did in 4 years of uni. So with regards to your proficiency claims I would raise an eyebrow. None the less I've found Jeff Atwood's coding horror blog very good at explaining various parts of the .Net framework and how MVC should be used http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html another good resource is Scott Hanslemans blog, I'm not sure if he has any MVC posts but in general its very good reading for all things .Net

Proficiency was definitely the wrong word. I understand the basic syntax and can create basic applications using these languages, hence my assignments and such. But i simply dont feel like i know enough to do anything meaningful.

As everyone else on the course seems to be in the same boat or worse, i am assuming that its just something that i will not fully understand until i make a start on proper projects in the industry, but i hate feeling like i dont have the knowledge or ability to do something properly so am just trying to improve on the fundamentals.

Quick edit to thank you for the link, that was very helpful and i understand it a 'little' better now. I understand seperating the logic from the visual to keep it skinnable etc. The controller is still a bit of a smudge for me, as at one point 'the browser is the controller' but in another they are on about more logic to manipulate the data which i thought was down to the model lol. Either way the 'skinnable' test is a good starting place for me so thanks very much.
 
Last edited:
Soldato
Joined
7 Apr 2008
Posts
24,406
Location
Lorville - Hurston
Proficiency was definitely the wrong word. I understand the basic syntax and can create basic applications using these languages, hence my assignments and such. But i simply dont feel like i know enough to do anything meaningful.

As everyone else on the course seems to be in the same boat or worse, i am assuming that its just something that i will not fully understand until i make a start on proper projects in the industry, but i hate feeling like i dont have the knowledge or ability to do something properly so am just trying to improve on the fundamentals.

Quick edit to thank you for the link, that was very helpful and i understand it a 'little' better now. I understand seperating the logic from the visual to keep it skinnable etc. The controller is still a bit of a smudge for me, as at one point 'the browser is the controller' but in another they are on about more logic to manipulate the data which i thought was down to the model lol. Either way the 'skinnable' test is a good starting place for me so thanks very much.

Sounds like you need to understand the concept of OO. object oriented. google and start learning
 
Associate
Joined
30 Jun 2011
Posts
128
I've been programing professionally now for four years and have to say that I learned more in my first 6 months of industry than I did in 4 years of uni. So with regards to your proficiency claims I would raise an eyebrow. None the less I've found Jeff Atwood's coding horror blog very good at explaining various parts of the .Net framework and how MVC should be used http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html another good resource is Scott Hanslemans blog, I'm not sure if he has any MVC posts but in general its very good reading for all things .Net

This is true. I didn't do a Programming Course at uni (Studied Computer Forensics) but I did small amounts of it, had a placement year doing it and in my spare time. I have been in a junior role for the past 8 months now and my mind has been blown and rebuilt with everything I have learnt.

MVC is probably one of the easiest concepts to get I would say. Use Asp.net website for mvc tutorials. Simplest form is the best way to learn this stuff.

I assume you will have but buy books, read a few blogs (don't take them too seriously) and practice. You'll get there. If you are still struggling ask your tutors for help, they will help you.
 
Soldato
Joined
12 Dec 2003
Posts
8,141
Location
East Sussex
The controller is the first thing that gets hit when you go to a certain URL. Say I owned the site foobar.com. I might have users on my site and users may want to view their profile. The URL for that could be foobar.com/user/profile. That would hit the "user" controller and call its "profile" action. An action is just a method (a function belonging to an object) that will dictate how to handle a request. It will delegate the actual legwork to models.

At a high level models are objects that hold some user input and methods to work on that input. I might have a contact form. This is going to take data from the user and that data needs to be sanitised. For example I might like to verify they've provided a valid email address. I could setup some validation rules in my contact form model. So a controller's action will take input from the user, pass it to the model then ask the model if the data validates. If it does then the action tells the model to send myself an email containing the user's message. Assuming everything went well I'd probably like to thank the user for taking their time to contact me.

Views are just the HTML for an MVC application. They can be compromised entirely of HTML but more often contain a bit of server-side code for stuff like iteration (e.g. looping over a bunch of forum posts) and simple conditional statements. The data they work with will be models.

Closely related to models is the Active Record design pattern. This is the idea of an object in code representing a row in some database table. Going back to the user's profile, the controller would pull the user's details out of the database by loading a model by its PK then pass the model to the view to display profile information.

Hope that helps. Explanations only go so far though, you need to get your hands dirty :)
 
Soldato
OP
Joined
3 Apr 2003
Posts
2,928
The controller is the first thing that gets hit when you go to a certain URL. Say I owned the site foobar.com. I might have users on my site and users may want to view their profile. The URL for that could be foobar.com/user/profile. That would hit the "user" controller and call its "profile" action. An action is just a method (a function belonging to an object) that will dictate how to handle a request. It will delegate the actual legwork to models.

At a high level models are objects that hold some user input and methods to work on that input. I might have a contact form. This is going to take data from the user and that data needs to be sanitised. For example I might like to verify they've provided a valid email address. I could setup some validation rules in my contact form model. So a controller's action will take input from the user, pass it to the model then ask the model if the data validates. If it does then the action tells the model to send myself an email containing the user's message. Assuming everything went well I'd probably like to thank the user for taking their time to contact me.

Views are just the HTML for an MVC application. They can be compromised entirely of HTML but more often contain a bit of server-side code for stuff like iteration (e.g. looping over a bunch of forum posts) and simple conditional statements. The data they work with will be models.

Closely related to models is the Active Record design pattern. This is the idea of an object in code representing a row in some database table. Going back to the user's profile, the controller would pull the user's details out of the database by loading a model by its PK then pass the model to the view to display profile information.

Hope that helps. Explanations only go so far though, you need to get your hands dirty :)

Wow thanks very much thats a massive help :)

Will just keep practicing and practicing until i get it all down!
 
Associate
Joined
19 Jul 2006
Posts
1,847
Can I ask...
I have a database application. Now Im going to have 6 views for each of the differnt tables in the database.
Would you have a different controller and model for each view or would it be best to have a controller called updateDB for example and a model called updateDB and do it that way?
 
Associate
Joined
28 Jan 2013
Posts
236
When designing an app you shouldn't really care about low level stuff like DB tables. Models should be used to 'model' your target domain entities, e.g. products, users, articles. In most languages the best way to organize the persistence is the repository pattern.
 
Soldato
Joined
17 Jul 2008
Posts
2,820
Location
London
Sorry didn't see this earlier.
Does it mean seperate the functions into different files is it all just a conceptual thing and no bearing on the files i am creating etc.
You only really NEED to split up views in separate files otherwise it would be confusing. But generally its good practice to separate controllers from models too. Mainly because different frameworks would expect files to live in a certain directory (different frameworks would have slightly different layout, but this is the general idea):

framework/ - whatever framework you are using
app/ - main directory for your application
app/controllers/
app/models/
app/views/

I get OOP etc but when comes to things like MVC i am just not sure what it really is. Figured better off asking here whilst i try to get better over summer.
Never really saw much use for oop myself (apart from in games) until I started working on projects that actually need it. Then its like "ohhh so that's what its used for". My uni course was pure C and then I worked as C code monkey for a few years. Hell you can do oop/mvc style coding using C if you want to.

Really all mvc is a way to manage data and split up your project into smaller chunks so its easier to understand and maintain. In web world, models are database tables, or data arrays if you are not working with database, or say csv files. Model's job is to operate on the data you need.

Controllers is the middle man between end user and your data, like tesco or sainsbury. Food products are data, shops are controllers and I guess isles are the views or some equally stupid comparison ;).
There is no academic help to be had as i am having no trouble doing my assignments, this is something i wish to work on in my own time.
Yup, completely expected. I am trying to get into mobile app development myself and its not that easy (also doesn't help that I don't have any killer ideas either xD). But best I can say, is to keep on slaving, do it wrong once, ask online, get flamed and in that flame there might be one or two sensible answers :).
 
Caporegime
Joined
18 Oct 2002
Posts
29,491
Location
Back in East London
MVC is not just for web. It's for everything. Separate the decision making from the presentation, and the authentication other technical decision making from the "core" of your application's domain. Data is an implementation detail of every system, and as such the thoughts of "Data" should take a back seat. Don't think your Model as "just the Data" because it is far, far more than that.

MVC is also not a system architecture pattern, it is a software pattern. This means you can have big MVC, small MVC, compound MVC, MVC within MVC, MVC adjacent to MVC etc. all (or none, or some) of that in one application.

The main point is to have an encapsulated domain - by encapsulation this means you only permit operations to be performed on your domain; You don't expose the domain objects themselves to the "outside" (more on this later if required) you only expose an interface (such as an API) that has operations on them. This interface will be your Controller(s). Again, don't think that every app only has one Domain. There are Domain within Domains. A data layer's domain is the persistence and retrieval of data. The SQL Server connector for that adapter has a Domain that covers connecting and interacting with SQL Server. A Web server's domain is receiving and responding to HTTP(S)/(S)FTP etc.

The Controller is the guardian. It decides if the request should be permitted or not. (Authentication.) It decides if the request is valid to a degree - usually only if mandatory fields have a value, and/or if it's a real request or a garbled one etc. perhaps there is schema validation (e.g. if the request is XML/JSON/SOAP/other transport.) It will then invoke the relevant actions on the Model.

The Model is the "Brain." "Business Logic"™ Goes Here. This is the stuff your application does because that's what your customer has asked for and not because of arbitrary technicalities.

And lastly there is the View. This is how your application is presented. The response is given to the view to present to the user of your system. Note this doesn't have to mean a human. It could be a remote application connecting to your HTTP webservice. The View in this instance would be the Response.
 
Last edited:
Soldato
Joined
27 Sep 2005
Posts
4,630
Location
London innit
In websites it's split into 3 broad areas:

Model: Encapsulates business logic. If you are going to ship a widget, then all the logic is here.

View: Encapsulates Presentation. This is the thing that displays the UI, tables of data etc.

Controller: Actions - click a button and the controller will send the results of your button click to the right place, then marshall the results back to the View.
 
Back
Top Bottom