tags:

views:

188

answers:

1

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

+1  A: 

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.

Mark Seemann
Thanks for your reply - OK, so that's fine, model binders aren't what I need to use then?Here's a rough idea of what I need to do. I will have a bunch of objects (consisting of a main table record, with various other tables hanging off it, some 1<-->1, some 1<-->0/many) listed on a table. Each will have to go through up to 3 screens, say, in the process of an edit, before the changes are committed. The users will be concurrently editing records, so each will open from the main search table in a new browser window/tab.
Mad Halfling
So say we have 3 instances of that data object, A, B and C. And 3 screens, 1, 2 and 3. A user may open A and go to screen 1, then 3 and the changes get updated. Then they may open B and go to screen 1, open C and go to screen 1, then C->2. Then B->2. Then A->1, A->3 (saves changes). Then C->3 (save). Then on B the cancel button is pushed, discarding the changes to it. So I have several instances of my data object in the process of being edited at the same time all by the same session, so I will need to store them in their respective states until their changes get committed back to the DB.
Mad Halfling
You lost me there, I'm afraid. In general, if intermediate state is not a part of the Domain Model, I wouldn't explicitly model its persistence. Instead, I'd just make the intermediate state serializable and persist it somewhere (custom database, SQL Server Session state, or whatever).
Mark Seemann