I have an MVC app I’m writing. There will be the need for multiple instances of the same page to be open, each accessing different records from a database, these record objects will also need to be passed through a flow of pages, before finally being updated.
What’s the best, and most correct, way of acheiving this – should/can I create a custom model binder that links to an object via it’s unique ID and then create each record-object in the session, updating them as I go through each one’s page flow and then finally calling the update method? Or is there a better way of dealing with this?
Cheers
MH
Technically, that would be possible, but I don’t think it is advisable. When you look at the signature of IModelBinder, you will have to jump through some hoops related to the ControllerContext if you want to be able to access the rest of your application’s context (such as how to dehydrate objects based on IDs).
It’s possible, but so clunky that you should consider whether it’s the right approach. In my opinion, a ModelBinder’s responsibility is to map HTTP request data to strongly typed objects. Nothing more and nothing less – it is strictly a mapper, and trying to make it do more would be breaking the Single Responsibility Principle.
It sounds to me like you need an Application Controller – basically, a class that orchestrates the Views and the state of the underlying Model. You can read more about the Application Controller design pattern in Patterns of Enterprise Application Architecture.
Since a web application is inherently stateless, you will need a place to store the intermediate state of the application. Whether you use sessions or a custom durable store to do that depends on the application’s requirements and the general complexity of the intermediate data.