We can discuss the issues you mentioned in the context of the visual designer, although the principles apply to the classic scope approach as well. An ORM tool such as OpenAccess is designed to manage complex object graphs. It just needs a bit of help from the side of the developer so that the context (OpenAccessContext
in the case of the visual designer) cleanly performs its tasks. In this line of thoughts, a very important thing is the disposal of the context. The wrong disposal of the context opens opportunities for hard-to-find failures, especially with the connections or memory leaks. Allowing multiple changes to take place before committing them to the database means that a context is active for an extended period of time. It is a valid case since you do not want to persist data that will be changed numerous times until the user has made up his mind. The thing of importance here is to dispose of the context as early as possible. There are some help articles that may give you a hint as to how to manage the context lifecycle on a per-request basis in ASP
. You have specified that you develop a web site and I can only guess about the actual technology that you use (ASP
). With regard to ASP
we have a richer set of examples that you may find useful and accommodate them according to your needs. Here are some links in case you haven't looked at them yet:
Best Practices in web development with OpenAccess
Best Practices in web development with OpenAccess - Part Two
You can avoid the reading of deleted entities by checking the changes like this
query = context.Categories.ToList().Where(x => !context.GetChanges().GetDeletes<Category>().Contains(x))
Your usage of OpenAccess
is correct as long as it does the job for you. Persisting changes in a batch is something that we support because it is a valid scenario required by cases such as yours. What worries us is the hard to track undesirable behaviors that you receive and which we would be most interested to resolve. Again, keeping the life of the context as short as possible (as it is designed to be light-weight and manage connections in a pool) will make sure that you make the job for OpenAccess
Do not hesitate to contact us to further discuss this or other issues.
the Telerik team
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Public Issue Tracking
system and vote to affect the priority of the items