This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi guys, How does editing an entity works in a web application in conjunction with PerRequestUnitOfWorkScope? With multiple postbacks, wouldn't a new unit of work get created on each postback? How would it figure out what to update? Cheers Joseph |
|
|
|
|
Yes, with PerRequestUnitOfWorkScope a new UnitOfWork will be created per request and held in the HttpContext.Current.Items collection. In terms of editing an entity, you would be loading the entity involved from the current UnitOfWork, making the appropriate modifications perhaps through some automated data unbinding or manually in code and then calling UnitOfWork.SaveChanges(). The UnitOfWork will know if the entity has been modified from its internal field tracking and send an UPDATE statement if required. If this is spanning multiple postbacks then I would presume you are either saving at the end and the changes would be collectively being submitted on each request (building up to the final commit) culminating in you saving changes, or you would be saving changes per postback which would lead to a flush per request assuming a modification was made per request. Does that cover what you are looking for? If not, a little bit more context on your scenario would be useful to discuss things more specifically :)
Jeremy |
|
|
|
|
Thanks Jeremy :-) To give you a bit of background information, I'm having a go at learning both ASP.NET MVC and LightSpeed at the same time. I'm trying to get my head around how I could let the user to edit an entity, with a few interactions like validations, then lead up to the final commit. I did thought about unbinding (presuming I was thinking about the same thing, which is to detach the entity, pass it around, then attach it again)... What is the recommend way to do this?
|
|
|
|
|
By the way... Since I'm quite green with ASP.NET MVC and LightSpeed, I could be talking in complete rubbish, newbie alert and apology in advanced... :-) |
|
|
|
|
I've found this forum thread back in late 2008 regarding "using lightspeed in a web application". Is it still a recommended approach for web application? |
|
|
|
|
No, I wouldnt advocate holding objects in session state. The latter approach which JD described in that post is the standard way of doing things however. The approach I would suggest you look at with MVC is structure your forms so that all changes associated with a submission are sent together. So for example if you are setting up a multi-step process you may just collate the changes via client side script; Or you may round trip changes to the server but have them pushed back to the next view as hidden fields. When you have an actual submission action, all the changes are sent together. You could then either wire up those changes to the entity using manual code - which may be favorable if you want to precisely control which changes are applied - or more generically using a Model Binder (e.g: http://www.mindscape.co.nz/staff/jeremy/index.php/2009/03/aspnet-mvc-part4/). The submission action can then call SaveChanges() if everything is valid. If you need interim validation either on a standard POST or via an AJAX call, you can always load and apply the changes to your entity, check .IsValid and enumerate the Errors collection to handle this. If you are interested, there is an example model binder which you can use as part of the community code project - https://code.mindscape.co.nz/repos/LightSpeed/Mvc/Trunk/Src/Mindscape.LightSpeed.Mvc/Binding/EntityModelBinder.cs Another reference point would be to have a look at the FilmFestival MVC sample which ships with LightSpeed.
Let us know how you get on :) |
|
|
|
|
Thanks Jeremy, I will give it go and let you guys how it goes. |
|
|
|
|
With the alternative approach JD mentioned in his earlier post "Another approach is to not store the object in session but maintain a reference to its ID somewhere (perhaps session, perhaps query string, perhaps hidden field, etc - just be sure to consider security here) and reload the object from the database, bind the values back to the object, validate and, if valid, persist it to the database. This will remove the need to re-attach as it will be attached automatically when you re-load the object each time."
Do I need to take LockVersion into account for optimistic concurrency? (i.e. maintain both an entity's ID and LockVersion) |
|
|
|
