I took the time to study a bit what you wrote last time. You're right, the context is not a cache (I misused the 'cache' word), and I use it to hold a graph of entities for the time of processing data, as you indicated.
I do have a specialized context class (LLBLGenContext), but it does not change the behavior of the Add method, as it is not overridable, so everything happening in Add is under complete control of LLBLGen (this class adds application specifics to the context, so it is merely an add-on).
I tried to debug a little bit to see where the problem arises, but the breakpoint set in the MarkedForDeletion setter is only hit when I set the flag manually (I did it in the class CommonEntityBase, which is base for all the entities). So, apparently, after setting it nobody changes it, but still, when checking again, the flag is reset.
To clarify a bit about the behaviors. These are classes which take the responsibility of applying cross-cutting behaviors to the entities. One of these behaviors is to ensure, for an entity hierarchy, that the whole hierarchy gets deleted. So, when the root is deleted implies that the whole hierarchy is deleted, so the whole graph is marked as deleted. Another behavior checks some permissions (does the current user have permissions to delete the entities?), which may load, depending on the application logic, again some other part of the hierarchy. The behaviors do not know of each other, do not know what the others do, when the others are applied, and in which order. So they must ensure that the entities with which they work are loaded. The logic they are comfortable with is: "I need the data, expecting that if the entities are already in context, use them, if not, load them, but make sure you have them all". Currently they use a query using the aforementioned context to load the subtree, expecting that the query loader is smart enough to add to the context only the missing entities, leaving the others in place and untouched. The behaviors are aware that the entities may be in one of the 4 states: unchanged, changed, deleted, and new, and they adapt their logic accordingly.
Please note that the example above is only for clarification purposes, such behaviors can be many and doing various things. The behavior orchestrator makes sure the behaviors are applied properly.
Currently, I use a UnitOfWork2 to add the changed entities and eventually commit them, using the flags provided by LLBLGen (IsNew, IsDirty, MarkedForDeletion), which apparently, get overwritten in the above scenario.
I checked the DataScope class and maybe I can find a way to use it (how can I provide my "improved" context?), but if the logic I need to use will generate the same problem, it is useless. Maybe I am wrong, but it seems to me that the DataScope is more like UI oriented, while I need something more server-like, lightweight.
Do you think I have a chance to get my problem solved: "fetch me the data (query), expecting that if the entities are already in context, use them, if not, add them"?
Attachments
Filename |
File size |
Added on |
Approval |
LLBLGenCache.zip
|
4,884 |
26-Nov-2018 13:30.27 |
Approved |