0

My general question is in a MVC patterned web app, what is the preferred way to scope and then update a bean after a request? I see 3 primary ways to go about it:

1) When the model is initially loaded, store it as a bean in the session. The user makes changes in the view, sends request. The controller grabs the bean from the session and from the request gets all the parameters that have new bean data, updates the bean with it's setters, sends the bean to the service layer to be saved.

2) Rebuild the bean from scratch only with request data: Model is initially loaded, bean is request scoped, and the view puts the beanID into one of its form fields (along with all other relevant bean properties), user changes data and sends request, controller gets the bean's id and all bean properties to be updated from the request and then builds a new bean from these and sends this object to the service to be saved.

3) same as #2 but after the request, controller makes 1 call to service layer with just the beanID that returns a complete bean that is an unaltered state, update the bean with the parameters retrieved from the request, send the updated bean back to the service layer for saving.

I want to use the first option because it seems like the easiest to implement and would be less taxing on the database. The second option would have less concurrency problems but it seems clunky to have to rebuild the bean from scratch, especially if there are bean properties that aren't relevant for this view that I would have to put in hidden fields so I could rebuild it accurately. The third options seems like overkill but thorough.

The details of the site in question: I am building a Java web app and trying to follow the MVC pattern. The basic functionality of the app is for managers to create plans for helping employees accomplish mutually agreed upon goals. The plan will contain different stages involved in accomplishing the overall goal and each stage will have specific tasks for completing the stage (so tasks are nested in stages which are nested in a plan). So the manager will build a "plan" and deploy it to the employee. Then the employee signs in, logs activity and marks task complete as he/she finishes them. The manager may occasionally modify the employees plan but the idea is that they would be collaborating on any changes to the plan after it was deployed. The manager can also run analytics on the employees data but that wouldn't actually change the employees data or the structure of the plan.

So, given that the employee is almost always going to be the only one who is accessing the data for his/her plans, I do not anticipate many issues where more than 1 person will be accessing data at the same time. That being said, I don't want to limit the site from growing should the requirements change and need more thread safety. I also want to use good coding practices to make it easier for others to improve and maintain the site.

Thanks for any feedback. I this is the largest scale project I've done to date so am seeing a lot of these problems for the first time.

Some of the research I've done:

how to choose the right bean scope

scope management for clean sessions

putting a java bean into the session

Community
  • 1
  • 1
arcademonkey
  • 109
  • 9
  • It really depends on your use case! As you mentioned, the second options is better wrt to concurrency and immutability, but a bit clunky if the beans are too big (but, if that's the case, you are probably messing something up somewhere else, as it smell of god class). If your application is single threaded, definitely go for option 1. – Diego Martinoia Sep 08 '15 at 15:53
  • @DiegoMartinoia Thanks, that is helpful just to get some reassurance that option 1 is reasonable in the case of things being single threaded. Seems it wouldn't be too difficult to switch to option 2 down the road if that changes. – arcademonkey Sep 09 '15 at 13:50
  • Uggggghhh. I'll hold you on that. Switching from mutable to immutable code WILL be hell, because INEVITABLY you'll exploit state somewhere. ;) Hope you can prove me wrong. – Diego Martinoia Sep 09 '15 at 14:11
  • @DiegoMartinoia Lol, good point. I am probably being too optimistic! I don't like taking shortcuts. For multi-threaded apps, is option 2 or 3 a fairly standard way to handle this situation or am I missing another option? My hunch is option 2 is the most in line with standards. If that was the case, I assume the way people deal with bean properties that aren't displayed in the view is to have a bunch of hidden inputs in the view to hold them so they can be retrieved by the request and used for rebuilding the bean. Is that right? Thanks for taking the time to respond to this stuff :) – arcademonkey Sep 09 '15 at 16:49
  • It really is up to you. If you don't have too many views, you may even create custom DTO's for each and have a converter from your internal representation to each external appropriate one, so that you'll never ever leak info (which is what I recommend anytime it's feasible). It all depends on the number/nature of cases: option 1 is not wrong per se! – Diego Martinoia Sep 10 '15 at 08:29
  • By the way, this comment thread is expanding beyond limit. Is it ok if I post it as an asnwer and we can close this question? – Diego Martinoia Sep 10 '15 at 09:40
  • @DiegoMartinoia Hmm, I've learned about DTOs yet. I'll look into it. I shouldn't have too many views. That sounds good to me about posting an answer, so yeah, go for it. Thanks again! – arcademonkey Sep 11 '15 at 14:02

0 Answers0