1

I m new to MVC and will appreciate if you can clarify my question.

What is a model?

Is it just Poco class having fields/ properties, for example a Person class?

Or is a model a data structure having data in it, for example List<Person> or List<Users> ?

Or as per asp.net a working Model is a business layer or service layer, can have business rules, logic, validation and i can talk to other layers?

Thanks for your help and guiding me.

crthompson
  • 15,653
  • 6
  • 58
  • 80
user576510
  • 5,777
  • 20
  • 81
  • 144
  • 1
    Related: [How should a model be structured in MVC?](http://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc/5864000#5864000) – Rowan Freeman May 28 '14 at 00:02
  • 1
    @RowanFreeman - note that link is about "classic MVC", which is different from APS.Net MVC (I've added link you've found to my answer, thanks) – Alexei Levenkov May 28 '14 at 00:15
  • Yes, but the principle is the same. It doesn't matter which technology you're using. If you're asking *"What is a model?"* in the context of ASP.NET MVC, all MVC implementations will have virtually the same answer. I've just read your answer @AlexeiLevenkov. At this stage I don't agree, but I'll look into it further since the information is new to me. – Rowan Freeman May 28 '14 at 00:25
  • @RowanFreeman - actually the principle is similar, but not the same. ASP.NET MVC is implemented in fundamentally different ways than more classic MVC. The stateless nature of a web implementation is partially the reason for that. But also that the type of MVC app you are referring to tends to blur the lines between UI and Business or Data layers, and most well designed web applications try to have very clear separation of these. Thus, in ASP.NET MVC the model is a View Model and not a data or business model, because otherwise the UI would be too tightly coupled to the other layers. – Erik Funkenbusch May 28 '14 at 01:14

2 Answers2

3

There are ViewModels and DataModels. Poco models are considered the DataModels. Poco models can also be used as ViewModels but its better to use separate models for views. Because a ViewModel can consist of one or more Poco models.

Here you will find more details: http://rachelappel.com/use-viewmodels-to-manage-data-amp-organize-code-in-asp.net-mvc-applications

View models and data models

Rahatur
  • 3,147
  • 3
  • 33
  • 49
  • thanks, I got it but will data model class called model or a filled data structure of that calss will be called model ? Also where will business logic ? They say to keep controller skiny, should it come inside model ? – user576510 May 28 '14 at 01:37
  • 1
    Business logic should not go into the controller/actions. It also should not go into the models. Otherwise the whole concept of SoC (Separation of concern) will break. Imagine you might need the same model on different pages with different data based on some logic. If you put the logic in the Model you will not be able to use that particular model anywhere else. Put all your logical functions on a service class and populate the data from there. The flow would be like this: Action -> Call Service method -> Service populates the model -> Return model to action -> Action send the model to view – Rahatur May 28 '14 at 01:47
1

One important note "Model" in "ASP.Net MVC" is different than "Model" in classic MVC design pattern, so be careful when looking for definition/resources. "Model in classic MVC" covered in How should a model be structured in MVC?.

"Model" in ASP.Net MVC is object (usually class) that ideally provides all data needed to render particular view.

There is no restrictions on whether such object used for any other purpose. If you view shows one particular item from data access layer (like Person) you can easily share the same object in data access layer and use it as view model.

Note that as of MVC5 views can't call methods asynchronously, so it is good idea to make sure all data is present in the model class instance rather than letting view to call DB/other remote services.

Community
  • 1
  • 1
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • 1
    I would have termed that definition of a model as a **ViewModel**. A ViewModel is an object that contains exactly what the view needs to display everything and nothing more. A model, however, is a representation of your domain. In the case of StackOverflow, for example, a model would likely be a user, a question, an answer, a comment, an upvote, a tag, a badge, and so on. These are usually represented as instances of classes, but that's more of how you implement or represent models, rather than an example of the concept. – Rowan Freeman May 28 '14 at 00:48
  • @RowanFreeman it is indeed "view model", but throughout ASP.Net MVC term "model" is used in that meaning (sometimes clarified with "view model", but often not). When classic "M" mentioned in ASP.Net MVC related text it often called "domain model" to explicitly distinguish from "model" (which by default is "view model"). – Alexei Levenkov May 28 '14 at 00:52
  • 1
    @RowanFreeman - What Alexi is trying to say is that ASP.NET MVC is primarily a Presentation layer framework based on the MVC pattern, and as such has no knowledge of any other layers, such as a business or data layer. This means that, by nature of the way ASP.NET MVC is designed, all models are in fact View Models. They may also be other kinds of models (data models, business models, etc..), although it's discouraged since ASP.NET MVC is based on SOLID principles and this would violate the Single Responsibility Principle. – Erik Funkenbusch May 28 '14 at 01:02
  • @ErikFunkenbusch can you please guide what you are refering here as business layer ? Is it same what is often referred as service layer ? What id does where it fits when we have controller and model ? What is its sequance of usage ? – user576510 May 28 '14 at 01:44
  • @user576510 - business layer can be many things... yes, a service layer could be a business layer, it might also be a façade over a business layer. In general, a business layer encapsulates your business logic. It's typically separate from your UI and data layers. – Erik Funkenbusch May 28 '14 at 03:49