MVC: I need to understand the model

Question

I’ve been working with the MVC template for some time, but honestly, I don’t feel that I really understand how to work with the Model and apply it. I mean, one can easily get away with using only the Controller and View and fine.

I understand the concept of the Model, but I just don’t feel comfortable applying it in the template ... I use the MVC template in .NET, as well as Wheels for ColdFusion.

“A model represents application information (data) and business rules used to manage data” - yes, I understand that ... but I just don’t understand how to apply it. It is easier to route calls to the controller and make the controller call the database, organize the data, and then make it available for presentation. I hope someone understands where my mess is ...

I appreciate your help in advance!

Answer 1

Look at it like that. When your client requests a page, this is what happens (massively cropped):

• It gets to your controller

• The controller receives the necessary data from your model.

• The controller then passes the data to the view. which will create your HTML

• Controller sends HTML back to the client

So, the client → controller → model → controller → view → controller → client

So what is a model ? That's all it takes to get the data you need to view!

• This is a service

• Data access

• These are requests

• This object mapping

• This is a critical test of the throw exception style.

Your controller should not write your requests if you stick to the pattern. Your controller should receive the correct data necessary to display the correct representation .

It is permissible for your controller to perform several other actions, such as checking the published data or some if / else logic, but not requesting data - just calling the services (in your model area) to get the data necessary for your viewing.

Answer 2

I believe that this is exactly what you decide to call different bits in your application. Which class that you use to transfer information from the controller to the view can be seen as / "Model".

Usually we call Model our essential classes, and we call the View Model “helper” classes, due to the lack of a better word, we use when a “clean” object (that is, one that will be stored in the database) is not enough display all the information we need in the view, but basically it's naming.

Your model classes should not have any functions; ideally, the model class will have only properties. You should see model classes as data containers, information transporters. In addition, they are (mainly) "dumb" objects:

 // This would be a model class representing a User public class User { public int ID { get; set; } public string Name { get; set; } public string Email { get; set; } } 

How do you actually convey information (whatever that means in your context) to form your controller for your presentation and vice versa? Ok then your model. :)

Answer 3

A model is a code representation of your base objects. Although some of the less data intensive systems may be lightweight at the end of the MVC model, I am sure you will always find the applicable application.

Take the invented (but realistic) example of the utility of the model:

Say I'm making a blog. There are Post objects on my blog. Messages are now used in and around the site and are added by many users to the system. Our system was encoded so that people injected HTML into their posts, but low and lo, people are starting to add the inserted text. This text uses the character "\ n" as the newline character.

With a model, this is a relatively simple fix. We just do a getter that overrides postText:

 public function get postText() { return this.postText.replace("\n", "<br />"); } 

Suddenly, we can affect the behavior of the entire site with a few lines of simple code. Without a model implementation, we would need to find and add similar functionality when using postText.

The model in MVC is all about encapsulation and the flexibility of the code base, as it evolves over time. The more you work with him and think about it this way, the more you will discover other cases that would otherwise be a nightmare.

- EDIT (you added your question above):

Take the same example and use your controller to invoke the database. We have 9 controller classes for vulnerable pages / systems that use Post objects. It was decided that in our table "Mail" will now be delete_fl . We no longer want to download messages using delete_fl = 1 .

With the correct implementation of our Post model, we simply edit the loadPosts() method, instead of looking for all cases on the site.

An important implementation is that in any large system, a model is a collection of files rather than a single monolith. Typically, you will have a model file for each of your database tables. User, message, etc.

Answer 4

 model: word, sentence, paragraph controller: for (word in sentence), blah blah... return paragraph view: <div>paragraph.text</div> 

The idea is to share problems. Why not just have controller logic in the view? The model represents business objects, the controller manages these objects to perform some task, and the view represents the result. Thus, you can change the whole view to another, and you do not need to rewrite the entire application. You can also work with people at different levels (model, controller, view), without affecting other layers to a large extent.

By combining the controller and the model, you make the code less maintainable and extensible. You basically do not perform object-oriented programming, since you do not represent things in your database as objects, you simply retrieve the data and send it to the view.

Answer 5

Here is how I explained earlier:

• Controller: determines which files are launched, are included, etc., and transfers user data (if any) to these files.

• View: everything that is used to display output to the user.

• Model: everything else.

Hope this helps.

Answer 6

The model contains business logic (i.e., significant algorithms) and the interaction of perseverance - usually with a database. The controller is an MVC framework: Wheels, Struts, .NET MVC. The view displays data that the controller retrieves from the model.

The big idea associated with MVC is that the view and model do not need to know about the controller, i.e. no connection. In practice, there is at least some connection that continues, but when well done, it should be minimal, so that it allows you to easily change the controller.

So, what should happen, the request goes to the controller, usually the front controller , where there must be some code that you use that either extends some controller object or follows some kind of naming convention. This glue code is responsible for calling methods at the right level of service , which packs this data inside some kind of helper - usually an Event object - and sending it to the correct view. Then the view unpacks the data from the Event object and displays it accordingly.

And when everything is done well, this leads to a domain model (aka model), which can be a test unit. The reason for this is that you have dispelled the algorithms from any dependencies in the structure or view. Such that you can test them yourself.