3

I hope this is on-topic here since I'm a bit new to the whiteboard...

I'm currently developing an application using ASP.NET MVC 5 (and WebAPI 2). One of my domain entities is huge, and is stored in a document database (MongoDb in this case). The reason it's so large is that it resembles the fields on a paper form that used to be used for this process. It logically makes sense for this entity to be as large as it currently is. I'm currently brainstorming the best way to handle the updating of this entity. I'm currently using a 1:1 model of this entity.

I'm going to explain what I'm in the process of implementing below, but nothing is set in stone at this point.

The View currently is split up into sections of this large model where a user can click on a section and then the section then appears as a form using some JavaScript magic for the end-user to update those fields (properties of the model). This is where I'm not sure if I'm doing this properly: The current implementation is sending the ENTIRE model to a WebAPI controller via $.ajax() to update the database with these changes, and if successful I update the View on the client side to display the current values.

I feel like I'm not really leveraging the ASP.NET MVC framework here though except for the initial display of the view, since I'm performing these updates on the client side.

Is this the proper way to do partial updates of a model (at least using ASP.NET MVC 5)? I don't really want to have to refresh the entire page by requesting a new view after one of these partial submissions using the server-side processing of forms. Should each of these sections be a partial view along with smaller models that can then update the larger entity? In this case I believe that I can then utilize the server-side processing for forms since it can then send a new partial view? (Am I even understanding how to use partial views here?!)

I'm a bit confused if you couldn't tell...

Improve this question
2
  • What should the behaviour be if the user decides, halfway through filling the form, to not submit the form or accidentally closes it? In your current design, filling the form and submitting it is an atomic action. If you send over sections to the server, you might be able to recover data in the case of an accidental closure, but it would be more work to ensure the entire form is filled before you do something with de data.
    – Bart van Ingen Schenau
    Commented Apr 26, 2015 at 9:11
  • @BartvanIngenSchenau Good question. With my current design, filling out a section and saving that section sends the entire model to the server (with only that section modified) for the update to occur. Therefore they can close or not submit a section that they decided to edit, without losing any changes they made to another section. No need for the user to fill out the entire form at once.
    – JNYRanger
    Commented Apr 26, 2015 at 13:48

1 Answer 1

Reset to default
1

Splitting your model into smaller models makes sense. You can use Ajax.BeginForm to submit the data of your partial view. So you can use your controller's action methods to call the service layer (your WEB API). In the action method you can create an object of your Main entity and populate it with your smaller model's values and send it to the API.

Improve this answer
1
  • This is exactly what I ended up doing.
    – JNYRanger
    Commented Jun 3, 2015 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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