MVC ...What is the point of the model?

[LumbergTech]

I understand, you can have a model..you can use the model to feed multiple views..ok..

But I have ALWAYS been able to do this just by using a data structure

lets say i have an array of "profiles"

If someone right clicks on the gui and selects "delete" for a certain profile, I remove it from that item in the GUI and then remove it from the datastructure...

I really don't see the benefit of models. It just seems like a huge pain.

I know I probably sound stupid, but I just don't see the point.

What I am having difficulty understanding is: If I already have the data in a structure and can access its pieces (say strings), why would I want to add another layer of objects into the mess loading the information into a model?

When I was using Ruby on Rails, it all made sense. It FORCED you to do it that way. I am having great difficulty imaginging how to do something similar with c++.

 

[PhatoseAlpha]

The model layer is supposed to handle all business logic, not just data structures.

Consider a more complex system, where parts interact heavily and logic is required on interactions.

For example, in your deletion scenario, imagine that any and all deletions must be logged as to when they happened, by who, and for what reason. Simply removing the datastructure from the GUI and then deleting it is not acceptable practice.

As an additional example, consider a typical electronic storefront, and the data in this case is an order. A new order is received via the controller. In order for that order to be processed though, lots needs to happen. You have to check the orders items and quantities against your own database, to see if you have enough of a given item. If you have the item locally, you can send it out. If it's at another warehouse, you need to first file a request to have it sent from that warehouse to you - not just a simple update. If you don't have any in stock anywhere, maybe you send a message back to your customer letting them know it's out of stock, and giving them options to cancel the order or choose a substitute. Perhaps it's a high volume item, and you want to keep your shelves reasonably stocked, so if the order makes your stock of an item drop below a critical level, the system emails the purchasing managed to let him know he needs to order more.

The model is for that kind of logic - required behavior that your data causes.

 

[Leros]

The model is your interface between the controller and the view. Your controller does all the logic and populates the model. The model then instantiates the view.

 

[Bulldog13]

http://en.wikipedia.org/wiki/Separation_of_concerns

 

[PCTC2]

As PhatoseAlpha said, it's the business logic. You really want to separate your logic. Your controller will handle any logic pertaining to requests, while the views will be views. You can EASILY have 'model logic' in your controller, but it isn't right. You want anything that modifies/ your data object in your model.

You want a search method? You could easily have a function in the controller, that when a request comes in, performs the search logic. Or, you can call Object.search(parameters) in the controller, and have the model do the search.

In short, you want a short controller. It handles requests from the router and that's it. You want any data logic in the model. And you don't want any logic except for templating logic in the views.

 

[Train]

In short, you want a short controller. It handles requests from the router and that's it. You want any data logic in the model. And you don't want any logic except for templating logic in the views.

this. I tell my team, "model heavy, controller light", if you find you have a lot of logic in your controller, it should probably be moved into a model.

Sometimes it's good to differentiate between model and view model, take a look at the MVVM pattern, it actually makes slightly more sense than MVC, as it seperates models out into two distinct roles.

 

[Leros]

this. I tell my team, "model heavy, controller light", if you find you have a lot of logic in your controller, it should probably be moved into a model.

Sometimes it's good to differentiate between model and view model, take a look at the MVVM pattern, it actually makes slightly more sense than MVC, as it seperates models out into two distinct roles.

What is the advantage of having a light controller and a heavy model? It seems backwards to me, you're mixing logic with your data structure.

My models have always been lightweight data storage objects, basically just the information that needs to get handed off to the view template. The controller's job is to do the work necessary to populate the model, so it can be used to instantiate the template.

I've done light model, heavy controller and it just seems messier.

 

[Train]

What is the advantage of having a light controller and a heavy model? It seems backwards to me, you're mixing logic with your data structure.

It's better than mixing your business logic with your UI layer (the controller)

My models have always been lightweight data storage objects, basically just the information that needs to get handed off to the view template.

So more specifically, they are VIEW models, not data models.

The controller's job is to do the work necessary to populate the model, so it can be used to instantiate the template.

Sort of. Most people would say the controller's job is only to be the glue that ties views with the business layer. If you use the same model (that needs validation for example) in different places in your app, you would be duplicating code by keeping the logic in the controllers and not in the model itself.

If you are firm about keeping your models as lightweight transfer objects, then in your business layer you actually need another set of objects, such as something that fits the repository pattern, to do the actual heavy lifting.

The problem is what if you need to port your app to a different platform? If all your logic is in the UI layer, you'll have to redo it. If all your logic is in the Model layer, then they are easily portable.

Like I said, you would probably like the MVVM pattern. I'm guessing it would make more sense. I've actually been slowly migrating away from MVC and am more along the lines of MVVM with a repository pattern in my logic layer.

I've done light model, heavy controller and it just seems messier.

Did you mean that the other way?

 

[PCTC2]

Here's an example I learned from personal experience.

Take a simple database web app programmed in RoR. Say you have a database for users.

The previous devs had controllers that were 1000 lines long and models that were 10 lines. It was painful to change any request handling logic. The search logic took up 150+ lines in the controller in the middle of a REQUEST HANDLER for the index method.

Once we rewrote the app, the controllers were less than 150 lines and the models were 1000 lines of data methods. Methods for graphic, searching, filtering, and parsing were all incorporated in the models and all you would see in the controller was "@records = User.search(params)". This way, we could completely rework the business logic of the search function without ever having to change the request handlers in the controller.

So in short:
The "wrong" way.
- The controller is filled with logic. Search logic, model population logic (when a PUT or POST request comes in, it parses it and saves it into the model).
- The models are basically just data structures with a few extra functions like "full_name" would return a concatenation of first_name and last_name.

The "right" way.
- The controller handles requests. PUT, POST, GET, etc and just puts the records or gets the records as needed. It only calls methods in the model so it is very light weight.
- The model has parsing logic so when field "A" is set in the a form, it gets passed to the model, the model parses it and saves it into fields "A1", "A2", and "A3" in the database. It also has the search logic and any cool methods for manipulating the data.

NOTE: I put "right" and "wrong" in quotes to say this is what is generally agreed upon as "kosher". I'm not trying to troll or start a flame war.

 

[uclabachelor]

I really don't see the benefit of models. It just seems like a huge pain.

I know I probably sound stupid, but I just don't see the point.

What I am having difficulty understanding is: If I already have the data in a structure and can access its pieces (say strings), why would I want to add another layer of objects into the mess loading the information into a model?

Don't over think this. The model in MVC is just that: a model of whatever underlying object you're trying to represent so that you do not end up with duplicates (but slightly different) of the same thing you're trying to represent.

lets say i have an array of "profiles"

If someone right clicks on the gui and selects "delete" for a certain profile, I remove it from that item in the GUI and then remove it from the datastructure...

If you don't make a profile model to encapsulate the delete() function, then anyone can code their own delete() routine. In the end you''ll end up with 10 different delete() functions in different areas of the code that may not function or do the same operation.

By having a model, all client code is forced to use model's delete() function if a profile needs to be removed. This ensures consistency across all code.

 

[IHateMyJob2004]

I've always made my models dumb. Model(s) are just data and a notifcations system.

I always have the views and controllers get notified of data changes taht they care about. They can make more model manipulations or do nothing.

Anyway, every book I have ever picked up always says soemthing slightly different about MVC.

The point is mostly the speration of concerns. Changing a value in a table is easy when the same code isn't trying to manage model like concerns.

Also, having a model prevents duplicate data. If every GUI pieces shares the data, you start having a nightmare situation where things need to remain in synch and on large projects, that can easily lead to mistakes (bugs). Data should be encapsulated in one area of your code base.

 

[AlexSerov]

The model is your interface between the controller and the view. Your controller does all the logic and populates the model. The model then instantiates the view.

Oh no. The model is between the controller and the view but it is not an interface in any sense. In general controller handles the request from the browser (for Internet applications). That changes the state of (our model of) the world in particular the state of our application and often changes the data in the database. The last data changed is what page to use next. After that works the view that has the only purpose to deliver information of what the new state of the world is to the browser.

Abbreviation CMV would be more appropriate than MVC.

View and Controller do not need to know anything about each other.

 

[cytg111]

http://en.wikipedia.org/wiki/Separation_of_concerns

This.

Dumbed down : write smart maintainable readable code.

You can throw patterns and patterns galore at a problem but at the end of the day, there is no cure for stupid.

I've seen mess upon mess upon mess, and i've also seen highly overengineered constructs .. and both are a bitch to work with.

Wanna make the next guy/girl working on your code happy? KISS baby, KISS all the way.

 

[exdeath]

Wanna make the next guy/girl working on your code happy? KISS baby, KISS all the way.

This x infinity.

 

[exdeath]

Model IS your application. View and Controller are simple detachable interfaces for the end user to interact with the Model. The application should exist and function self sufficiently in the Model even when a View and Controller are not present.

 

[LokutusofBorg]

http://martinfowler.com/bliki/AnemicDomainModel.html

 

[cytg111]

http://martinfowler.com/bliki/AnemicDomainModel.html

I know Fowlers greatest hits and all, but I have no idea what he is talking about in that article.
It seems to me that he's backing everything behind the oh godly statement : OO. Therefor it must be good.

And i know I must be the fool next to Fowler. Right?

I've had a few glasses, so bare with me ;

"This is worthwhile iff you use the powerful OO techniques to organize complex logic"

and by mentioning j2ee's entity beans in a non OR mapping fashion....

.... Here is my sober wisdom on O/R mapping frameworks, say, like for java/c# N/Hibernate.

They're shite.

It was not ment to be. You have a table, a few billion rows long, and you expect the virtual machine to happily cruch away at a billion objects, cause your idea of good design demands it?
Never mind the bastard childs of exceptions you'll have to eat cause your framework didnt anticipate "this O/R mapping construct".

It's stupid.

Right tool for the job, always.

I could go on, but it's a never ending story.

 

[Train]

You have a table, a few billion rows long, and you expect the virtual machine to happily cruch away at a billion objects, cause your idea of good design demands it?

Your doing it wrong, way wrong.

 

[cytg111]

Your doing it wrong, way wrong.

I keep forgetting this is the internet. Everyone is special. And running for the olympics.

 

[LokutusofBorg]

I keep forgetting this is the internet. Everyone is special. And running for the olympics.

Personal slights do the opposite of proving your point... just sayin'.

 

[cytg111]

yes, much like oneliners.

Did 'Train' have a point or not? We dont really know do we? Only thing we get from his post is -"Me so smart, you so stupid, me so right, you so wrong".

And that is just plain internet-retardism for you right there.

 

[Train]

The point was pretty clear, if you, in your own words,

expect the virtual machine to happily cruch away at a billion objects

... then you are using ORM's wrong. If you think ORM design demands it, you have a severe misundersanding of ORMs.

If you were looking to take a moral high ground, I think you already disqualified yourself with

They're shite.

and

It's stupid.

Aside from the fact that ORM's are off topic of this thread anways.

 

[Markbnj]

One-line zingers and ad hominem responses are in approximately the same category of offense in my mind. With the rest of the Internet apparently dedicated to making an impression in 140 characters or less, I'd say there's plenty of support for the snappy rejoinder in the world. We, at least, should be able to fully express what we're thinking when we respond to something.

That said, I didn't understand the comment either, so I'd invite cytg111 to say what he was thinking when he mentioned a virtual machine crunching away at a billion objects. As it stands the statement is not of much value.

 

[Bulldog13]

That said, I didn't understand the comment either, so I'd invite cytg111 to say what he was thinking when he mentioned a virtual machine crunching away at a billion objects. As it stands the statement is not of much value.

Maybe he is calling .ToList() too early on an unenumerated list ?

 

[cytg111]

If you were looking to take a moral high ground, I think you already disqualified yourself with
....

- That would be true if you were an ORM framework, i am guessing you're not.