How to design the interface for the Model in Model-View-Controller?

I understand how the MVC pattern works, but I've always had this question. If you have a big Model with many functions delegated to various classes, do you have to define a big monolithic interface with all the methods to manipulate and query the Model?

Or, can that model be partit开发者_开发百科ioned to many models, that talk to each other, and then you can manipulate them with their respective controllers?

Thanks

---

The "ViewModel" concept may be helpful here -- it's also referred to as "view specific model" by Phil Haack in the book "Professional ASP.NET MVC3".

A lot of auto-tooling or "scaffolding" generators look to create a single page/interface but there is nothing preventing you from making a multi-stage process for a large model.

One option would be to create View Models for each stage of the process (ie. BigProcessPartAViewModel, BigProcessPartBViewModel, etc) and then generate a controller that process each of these with separate views. Obviously you'll need to manage state across multiple stages, perhaps with a database or session.

Additionally, your model is your model... it is NOT data access. So you may need to have an additional model that handles in-process state as well as a data access design that allows for a multi-phase transaction.

---

There is nothing that says that your Model needs to be a single class or entity.

For example, in Spring MVC, the model is basically a Map that you construct in the Controller, with keys and values.

---

Interface segregation is one of the SOLID which stands for 5 basic principles of object-oriented programming and design. It says that if your interface becomes too 'fat' it needs to be split into smaller and more specific interfaces. More details on Interface segregation wiki page