2

I'm in the process of designing an application structure and am currently thinking how to structure my asp.net MVC5 front-end.

My application is wizard-like with tabs for each step. It's not a strict wizard as in you need to finish previous step to get to the next one but it's close.

There will be 12 tabs/steps and each of the tabs can hold (but not necessary) up to five subtabs (customers). In a rule of the thumb calculation I think there could be max 12 tabs x 5 clients x 15 fields (average...) = 900 fields on the front-end. This is worst-case, reasonable would be 12x2x10 as I currently don't have full specs for all 12 steps.

My question is should I keep this in one huge tree ViewModel or should I perhaps save each step into DB? So build it from PartialViews or standalone Views. Data will need to be persisted in DB at some point.

During input I will need data from other steps, example - in Step 8 I will need to know what was in Step 3 etc.

Single ViewModel - I have all data ready on-hand at any time, but how is the performance, a quick search got me this SQ question.

Standalone ViewModels - I would need to pull data from DB on-demand, which could be quite often. Data is persisted at each step which is a benefit if errors occur and data is not saved in time.

  • Should it be possible for the user to continue filling in the wizard where he left off if he (accidentally/intentionally) closed the application/page? – Bart van Ingen Schenau Nov 14 '16 at 11:17
  • @BartvanIngenSchenau yes, this is already a requirement. User can close application and continue later. – Iztoksson Nov 14 '16 at 11:36
5

I have all data ready on-hand at any time, but how is the performance...
I would need to pull data from DB on-demand, which could be quite often. Data is persisted at each step which is a benefit if errors occur and data is not saved in time...
this is already a requirement. User can close application and continue later.

It sure sounds like you know what you ought to be doing, and the reasons why. Persisting data as the user progresses through the steps is not "abusing" the database, especially since your requirements dictate that you do so.

A viewmodel or controller should maintain its focus, not try to encompass everything. One of the uses of these structures is to avoid a single giant entity representing global state, because it's unwieldy to work with and often performs poorly. If you need data from previous steps (i.e. other viewmodels), then fetch it.

Yes, you'll have to make more trips to the persistence layer, but that's not a bad thing. Don't worry about that extra network cost unless and until you've built the thing out and profiled it to prove there's a problem and that's where it is.

  • After some further consideration I decided we will persist every step into database, mostly for reasons you stated and also some other technical details - multiple renders of the same partial view which turned out pretty hard to do properly. – Iztoksson Nov 15 '16 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.