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
|
Apologies if this is obvious, but I havent worked out how to get the UOW that an Entity belongs to. Reason I ask is that Im doing some processing in the OnSaving event and I figured that an Entity object will always have an associated UOW object at that point.
Thanks in advance |
|
|
We don't currently expose that information on an Entity. The reason for this is that we normally expect a unit of work to be relatively tight in scope, so you would normally know what the unit of work is anyway. The Repository and UnitOfWorkScope APIs may assist with this if you are using those patterns. We can add a way to get the UnitOfWork but we would like to understand the need a bit more first. Could you say a bit more about what you are wanting to do with the UnitOfWork within your OnSaving handler? We are just a bit unsure about what UOW facilities you would need at that point. Thanks! |
|
|
My model defined that when a particular value changes (therefore use the OnSaving event) that other Entities be updated to reflect this change. These other Entities changes are a result of a computation based on the chnages on the current Entity. Now it would be great if these "consequential" changes became part of any active transaction applied to the "current" Entity, hence the desire to have access to the UOW currently "attached" to "this" Entity. Make sense? If I could suggest something: If it arrived as a property/Field of the eventsArg or another parameter of the OnXXX events? This would keep the the Entity "clean" and with the same intent the designers had/have for it. |
|
|
Are those other entities not part of the unit of work already? Or do they need to be attached to the unit of work associated with the saving entity? In the former case, one approach you might want to consider is handling the PropertyChanged event rather than handling the Saving event (or overriding the OnSaving method). This would allow you to apply the changes to the other entities immediately (i.e. before the save process begins), so that when you call IUnitOfWork.SaveChanges, the other entities are already dirty and will be saved as part of the same operation. We would be a bit nervous about modifying (and wanting to save) other entities in the UOW within the Saving event because the list of entities requiring saving is built before the Saving event is fired. Therefore entities which become dirty during the Saving event will not get saved as part of the SaveChanges in progress. Additionally, if one of these other entities is already dirty, but is further modified during the Saving event, the additional changes may or may not get saved depending on whether that other entity has already been processed as part of the save batch. (Of course you could call SaveChanges within the Saving event and you will still be in the same transaction scope, but that's not a scenario we've tested and we'd be a bit unsure about how the "outer" save would react when it resumed, got to the next entity on its list and found that it had been unexpectedly saved by someone else!) Or maybe I have completely misunderstood what you are describing *grin*? |
|
|
no it make perfect sense what you have said. I can, and will, do what I need to do in the PropertyChange event and not in the Saving event. To answer your first question - Not necessarily, the other entities have their properties adjusted based on the new value in the property being modified - as defined by the model / business logic. So the idea is that wherever in the main code this value is changed that the other enitities have their properties computed and adjusted accordingly - the other entities will not have been included into the UOW by the main code.
But this still leaves me with no access to the UOW associated with the object when "PropertyChanged" is called. |
|
|
We have added a facility to get the UOW associated with an entity. Note we have made this a protected (not public) property of the Entity class in order to discourage casual use! (The reasons for wanting to discourage it are as discussed earlier in the thread.) The new property will be available in nightly builds dated 14 Oct 2008 and above, from about 12pm GMT. We would still encourage you to check out the Repository pattern (see IRepository and RepositoryBase, and the ASP.NET MVC sample for usage, and the UnitOfWorkScope classes) as an alternative design. Generally we feel that an application should usually have a pretty good idea of which UOW it is using at any given time, rather than needing to find out from an entity. We have added the property anyway because we don't want to hold you up any further, but we do think it's worth having a look at the repository approach if you haven't already done so. |
|
|
tyvm. This will allow me to move forward (or rather get rid of some kludgy code :P ) And thank you for your advise regarding Repository pattern. My problem is that I have created an object model that needs to be used by both a web app and a windows forms app. And from what I understand different scopes and repositries patterns are needed depending on the type of application being created. |
|