Rank 1
1. When it comes to the EntityDiagram context (Linq to SQL equivalent DataContext) how do I manage this in an ASP.NET web application? I want to run things as quickly and efficiently as possible on the web server so I don't believe wrapping each request in a using statement and creating a new context for every operation may be most efficient. Would I perhaps use something like shown here and create a per thread context? http://www.west-wind.com/weblog/posts/246222.aspx
2. I am guessing that I don't wrap anything with transactions either as I don't see anything along those lines as a property to set on the EntityDiagram context. Of course thinking through it I am also guessing that when the .SaveChanges() is called on the context, that if an error occurs on writing to the database, then none of the changes would take - so I guess technically it is wrapped in a transaction - hah - there - answered my own question.
3. So I know there are improvements coming and that a new OpenAccessDataSource is being worked on to assist with Visual Design - but I am working on a project immediately that involves using a lot of Grids and Dataforms within Formviews. I am trying to understand the best way from code to handle the updates to the forms and grids using the OpenAccess generated Entity Diagrams. Getting the data is easy - more ways than I can count to pull the data - .GetAll<T>, context.Object.ToList<>, Linq query, etc.. simply set as the DataSource for the Grid or FormViews. Any tips on enabling the updates, deletes, inserts and tying those methods quickly to the new OA Visual Designer way of doing things. If this is an amature question please feel free to admonish me - but I really want to move fast with this new product
4. To get the pest database performance, it seems that hooking a WCF service up to serve the OA objects might be best. I noticed that you have WCF Services based Generation Wizard that can be downloaded. Does this interact with the new Visual Designer or are these kind of seperated pieces? Please forgive the questions and thank you for what looks to be an awesome product!
1 Answer, 1 is accepted
1. Yes, you are looking at the right place, the per-thread context is the best and proven approach with OpenAccess. We also have recommended this approach to our customers in the following blog post. It discusses the management of the IObjectScope but the rules are absolutely the same, it is just a different API.
2. Yes, you answered the question right. The CRUD operations are internally executed inside a transaction.
3. First, I should mention that for the next service pack release which is coming soon, the OpenAccessDataSource will be working with the new visual designer entities and the new OpenAccessContext. Doing the CUD operations in code is usually done by subscribing for the appropriate events of the UI controls, then obtaining the object by its ID and then assigning the required values to it, or deleting it from the context for example. I would suggest you downloading the following code library example which is also part of our QuickStart. There we are using the old API in a disconnected scenario, but I think that it should really be enough for getting your started as the CUD operations are there performed in code and the same approach will work with the new context as well.
4. Yes, the DataServicesWizard does work for creating WCF layer over OpenAccess but it is not yet fully integrated as part of the product. So it is still a separate product that you should download from the Telerik web site and install it on your machine after you have installed OpenAccess.
Zoran
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? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.