views:

284

answers:

4

Hi, i build a small application with asp.net mvc framework. I have one question. I built n-layer structure (controller -> service layer -> repository layer) of app and created a wizzard for collect data from user. Some data which comes from repository(data layer) need to save for next step(for example when user press back button on wizzard), this is not data which entered by user. For some reason I need to cache this data from repository (for disaplying when back button pressing). For my application I will save this data in session and I don't know who must save this data. From one hand it must be a service layer - and I need to send sessionstatewrapper to him. But for business logic of application - for service layer I need send all data from wizzard and separating this data for some steps it is just defferent view for collecting data and processing this data - it is work of presentation layer (for example controller). Any ideas for help ?

P.S. Sorry for my english =)

+1  A: 

I would say that this is something that the frontend should take care of this. Your service layer should not need to worry about the fact that this data is collected in a wizard and that it is a web based wizard so your frontend is stateless. Consider this: what would you have done it it was a Windows based app? Your "frontend" would maintain the state for you.

But that is just my $0.02...

veggerby
+1  A: 

It seems that you have a pretty complex application right there. As you seem to not be familiar with the MVC framework you are using, I would recommend to start of with extremely simple things. This means that, for instance, you do not save the data until the end. Warn your users and meanwhile, learn the maximum about the MVC you are using. When you will have enough knowledge, then go back and add that functionality.

BTW, in MVC:

  • M is the Model, the data you fetch from files, databases, stdin, etc.
  • V is the View, the presentational layer. It displays the data, it's the frontend.
  • C is the Controller, it controls everything in the application. It fetches data from the model, processes it, sends it to the view, waits for a response, gets the response from the view, processes it, acts accordingly.

My 2 cents are that you should make the Controller take care of the state of the wizard.

xav0989
Thanks for you attention. But I am not sure that controller in mvc has such many responsibilities. I think that it must only provide data from model layer to view and collect data from view and move it to model for process. What do you think about this ?
Maksim Kondratyuk
+1  A: 

Is it a requirement that you save it in session, or that you save it in memory on the server.

In your case I would have used Enterprise Library Caching application block. With this you can create a cache of Key/Value pair where the key is the user id and the value is an object containing the information you would like to store.

Using EntLib you can access the information from the layer in your application that makes most sense, and do not need to worry about when you have access to session state.

EDIT

Place the storing of session data in the Model. The Model is responsible for looking after data. The View shows data to the user and the Controller controls.

Shiraz Bhaiji
Saving in session - its temporary solution. For nex stage of developing we will moved saving this data into database or distributed cache. Adn question is which layer of application has to control saving this data.
Maksim Kondratyuk
A: 

If you're passing data back and forth through a wizard, the first thing I think of is TempData. This is precisely one of its uses - you need to persist something to the next (or previous) page only, each and every step. Of course, since TempData uses Session, at the end of the day if you have a need to use Session directly, it's always an option.

This is the type of thing the Controller should be managing. Your service and repository layers should provide the controller whatever data it needs, but the controller itself should be managing the persistence of this data throughout your wizard. If you look at it as "view data" for your wizard pages (I don't know if that is representative of your data or not, but it may be) that may make it more clear which tier of the system should be responsible for it.

Kurt Schindler