Is there a standard model for the "controller" relationship when trying to implement good ASP.NET MVC?
I'm not sure if this question is meaningless or not, tell me if it does. I am wondering if I can create my models like one for each table in my database, or are you doing one for each controller? Is there something missing here?
From what I've read, the model is supposed to be a representation of real business objects, so I just want to make it one big model, or separate them based on things in the application? based on real user / client perception of data?
Thank you for your advice.
source to share
There is nothing wrong with controllers using generic models. But trying to serve every controller with the same model doesn't make sense.
Models and controllers are really unrelated and shouldn't be. Models are also not directly related to how data is stored in your application.
Models encapsulate data. Their design should be dictated by the data they encapsulate. System requirements dictate which models you need and what data they need to store.
Don't try to convince him. For this request, define what you want to show in your view and how it will be displayed. Determine what the appropriate model will look like for this scenario. If it already exists, use it. If not, create a new model. Save your reassessment later when you know what your needs are and can find similarities between the models.
Models can also contain other models. Think of a model for a sales report. You will have a model for the report, which will contain not only the name of the report, but also a collection of other models that make up the report items.
source to share
It depends on what you mean by "Model". If by model you mean the level of business rules of your application, then in terms of numbers there is no relationship. One model of this type is used for any number of views to be built.
Personally, however, I would not bind any view to any model, but create an intermediate layer called the ViewModel that essentially constrains the data from your model to fit a specific view. In this case, the relationship is one-to-one. This is essentially how Presenter templates work. Each view is strongly typed for its own ViewModel, which is populated from the model level.
Models do not need to have a personal connection to the database. How you store data, your model is different from how your "Model" uses that data.
source to share