[Solved] Q2 2010 data model context vs scope

[Eddie Conner]

In the new video for Q2 2010 (http://tv.telerik.com/watch/orm/getting-started-with-new-visual-designer-openaccess-orm?seriesID=930), it shows using the data model context to query and access the data. For example:

using (NorthwindDbContext dbContext = new NorthwindDbContext())
{
}

However, from the older OpenAccess videos it shows using IObjectScope.

What are the best practices and differences of using these two methods?

[Dimitar Kapitanov]

Hello Eddie Conner,
Currently we have two sets of API that can be used separately- The Visual Designer for OpenAccess (and all technology bound to it) and The OpenAccess Classic as we call it - it is the regular API that OpenAccess have used for many years. We are changing that for good, giving priority to the new API over the old one - that is the actual rpoccess taking place as of now. You understand however that we cannot throw the 'old API' just away: a lot of customers have built applications over it, so by no means we are going to remove that from the product in the foreseeable future.  However with time only the new API will be promoted and developed further. More and more of the old API will be 'freezed', thus it purpose will change with time to strictly "back-end compatibility" status. It will be a long process with a lot of stages... My suggestion is that if you start a new project or you just evaluate our product, you should concentrate on the new API approach.

Sincerely yours,
Dimitar Kapitanov
the Telerik team

[Randall]

Hi,

We are evaluating OpenAccess for migrating our existing software product from an in-house framework, and are experiencing some difficulty understanding which of the "Classic" API features are not yet available in the new API. Naturally, we want to evaluate with the newer API, plus the trial download no longer seems to contain the older wizards :-). 

1. Is there a summary available of features limited to the "Classic" API, as of Q2 2010?

2. Specifically, are artificial fields and types available in the new API, and where is this documented? Would I need to generate my model as XML or could I use the attributes approach?

3. Is there a new edition forthcoming of the Step-by-Step Tutorial (aka OpenAccess Made Easy)? This looks very useful, but it relates wholly to the older API, as far as I can tell. 

Thank you!
-Randy

[Serge]

Hi Randall,

 We have not stripped OpenAccess of the wizards. What we did was separate the menus for the classic and domain model. You can find out how to change menus in this blog post.

There is no summary of what is not available however I can elaborate a bit on this point. What is currently not supported at all by the domain model is the change tracking capabilities of the scopes. However we will be providing support for this in the near future. 

We have no documentation about using artificial types and fields with the new API, however it is possible and even better than before. How one would go about using the artificial fields is the same, however the setup of the artificial types is now way easer. We have provided an object model you can modify in code and just add the artificial objects there. You can have a look at the model here. I am attaching a sample project using artificial fields with the new API.

Prior to the Q2 release we put our effort into refreshing and updating the help installed with OpenAccess and the online help. However due to a growing interest in the OpenAccess Made Easy we are considering updating that document. 

I do hope this helps, if you need more information please do not hesitate to contact us back. And rest assured any trouble you might find with the new domain model we will try to resolve.

Kind regards,
Serge
the Telerik team

[Randall]

Thank you, thank you, thank you, Serge!

Your explanation very much clears up some misunderstandings we have. We will try to continue our evaluation with the new API's and Wizards if at all possible.

The ability to add fields, types and relationships at runtime is one of our key requirements, as our customers have individually customized database schemas. The example you provided will get us a long way toward prototyping this. Since no XML configuration file is required, the artificial entities can truly now be added on-the-fly!

Thanks again,
-Randy

[Erkka]

Hi!

I have been poking around the Artificialfieldswithmetadatacontainer sample
and it has some great solutions in it. However I'm a bit confused about how the
artificial fields are stored. Can they be saved in a external Xml file or somewhere
else? In the sample they are not saved anywhere but generated over and
over again. Does the metadata container have some kind of save method?
At least loading is documented quite nicely.

Thanks in advance!

-Erkka

[Serge]

Hello Erkka,

Artificial fields cannot be stored, because if they could be stored they would not be artificial. There are no means of storing artificial fields by default. You could if you tried to implement some way of storing them, however the generation does not seem as a complicated or even slow operation so it should not be a problem in terms of speed. 

While it might bother you that they are generated every time, it should not be a problem, the overhead will be minimal. 

I hope this is helpful, however if you still have concerns please be sure to contact us back.

Sincerely yours,
Serge
the Telerik team