views:

37

answers:

1

background: i came on board to a team/ project that have developed a .net home grown mvc type architecture with home grown Ajax calls to persist data in a series of 6 screens to a context object on the server to maintain state.

question 1: this seems like using mvc just to say we use mvc and not the mvc way of doing things. it feels to me like they synthesized the post back model by using mvc ajax calls and server context objects to persist state. can someone explain the real MVC way for getting this done?!?!?

background: when the wizard is kicked off it loads the user data into a large object from the mainframe, but this is abstracted via a data layer. this object has all the personal info and everything else pertaining to the particular user. this is a static object and takes some time to load, so much so that if another call is made it may very well be still creating the original object and fail on the second call... so they have threading as an answer to this problem. this user object is the one that gets passed via Ajax to the context object and persisted on each next/ previous button click in the wizard.

question 2: this seems like a terrible way of getting the result of a wizard of 6 pages that allows next/ prev. navigation and i have never seen an app take so long to load over the web that threading needs to be implemented to avoid errors if the object is not ready for use. how would this be done on sites like stackoverflow and what should have been done in this app?

A: 

Answer to question 2; The "wizard" interface seems like a perfect candidate for becoming just a single page. Why not just have 1 visible div on the page, and 5 hidden divs? Then no reload necessary to go back/forward to wizard screens.

Answer to question 1; Its hard to tell from the very little information we have about the app if it faithfully implements (at least in some part of the application) the mvc design. Certinantly, In every project there are not jut one, but a number of patterns being used. I'm not sure anyone could say from the limited amount of information given, whether the attempt to use mvc is true-to-form or not.

Steve
well with question #1 i trying to figure out if you are going to be passing an object to the server albeit via AJAX on each page then why not use the classic post back model instead of forcing MVC to do what the classic model does already by default.
kacalapy
Use of MVC doesn't exclude the use of postbacks... far from it... one could easily implement their javascript client-side application with an MVC design and that code might cause a postback, or one could implement their server-side code in MVC form where the postback is handled by a controller, and the model and view concerns are still well encapsulated within model and view classes. And this is my point, the information presented so far isn't enough to make any judgments about if/how-well the MVC pattern is implemented in this case.
Steve