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
|
As is the case with almost every app, our (thick client WPF) app uses lots of persisted "reference data". I'll call them "Reference Entities" for the sake of this post. These are items that you would typically see presented in cascading combo boxes throughout the application or in lists that users might select from. Real world examples are things like "Accounts", "Categories", etc... These "Reference Entities" are never edited within the context of the app. In terms of an object graph, these items are set as property values on "Transactional Entities" which are edited. When we materialize these, we are detaching them from the UnitOfWork that materialized them and then we are letting the UnitOfWork go out of scope. Ideally we don't want the "Reference Entities" to be "tracked" in any unit of work. We started to see issues when we began to introduce caching into our application (using the MS caching block, not LightSpeed caching). We are observing that a cached "Reference Entity" gets a Unit of Work propagated to it from a "Transactional Entity" when set as a value. Later, when that cached "Reference Entity" gets used again, there is some unit of work mixup that is causing failures during saves. We are considering cloning cached "Reference Entity" objects when they are served from cache(which has its own drawbacks) to prevent the unit of work from being propagated and passed around unintentionally. Is there any recommended approach for caching what I'm referring to as "Reference Entities" such that the UnitOfWork is not globally communicated in otherwise isolated environments? |
|