3 Answers, 1 is accepted
You are totally right that ObjectView can offer you easier and faster way to bind data control to domain context. The documentation in the "Old API" describes how to use the type, but misses one important topic - how to use it with the current API, and it will be updated accordingly.
I have prepared a quick sample how to bridge the gap between the new context API and the ObjectProvider/ObjectView data binding approach. Please see the attached zip.
In nutshell you should extend the domain model class using a partial class and add an additional property:
//Expose the ObjectScope of the context for the ObjectProvider to consume
public
IObjectScope Scope
{
get
{
return
this
.GetScope(); }
}
Then you can add ObjectProvider and ObjectView from the toolbox to your forms/controls.
Add the following code in the forms/controls code behind:
private
EntitiesModel dataContext =
new
EntitiesModel();
public
Form1()
{
InitializeComponent();
this
.objectProvider.SetObjectContext(dataContext.Scope);
}
Now you can bind you control's DataSource property to the ObjectView instance.
Getting back to your question what is the difference:
- ObjectView supports IQueryable as underlying collection for the data source, which means you can easily query data, shape the result and enjoy LINQ in your code. For example you can have server side sorting and paging.
- ObjectView is wired to the data context so you can enjoy automatic persistent object tracking which enables you to employ easily SaveChanges() method without any additional code.
Don't hesitate to contact us again if you have any other questions.
Viktor Zhivkov
the Telerik team
Also just wondering if i have a form which as 3 objectviews for 3 different tables, do i need to create 3 different objectproviders and assign to the different objectviews or can i create one objectprovider and assign that to all 3 of the objectview? im a little confused as it would seem to get messy having to create an objectprodier for each object view on a windows form?
Please let me apologize for misleading you with my last post.
I regret to say that this statement is not true:
"Getting back to your question what is the difference:
- ObjectView supports IQueryable as underlying collection for the data source, which means you can easily query data, shape the result and enjoy LINQ in your code. For example you can have server side sorting and paging.
Actually, the ObjectView is an obsolete component in our product and has not been updated after the new context-based API, directed to LINQ development was introduced.
If you want to do sorting and filtering using ObjectProvider you have to use OQL as the query language instead of LINQ.
OQL has similar syntax to SQL, and it issues queries as strings not as expressions as LINQ does.
If you like to filter your data on the server side you can add a "WHERE" clause to the OQL like this:
objectProvider.OQLStatement =
"SELECT * FROM CategoryExtent AS x WHERE x.CategoryName = 'Hatchback'"
;
In order to sort data add "ORDER BY" clause like this:
objectProviderCategory.OQLStatement =
"SELECT * FROM CategoryExtent AS x ORDER BY x.CategoryName ASC"
;
Our online documentation contains a lot more information about OQL and how to use it.
Paging results get very tricky to do using OQL.
Depending on your various scenarios you can use ObjectProvider/ObjectView or BindingSource.
- ObjectProvider/ObjectView is good for plain binding for DataGridViews with sorting done via OQL and no paging;
- BindingSource + manual handling of data context and LINQ queries is good for more advanced scenarios;
Regarding about your question about multiple object views - you need a pair of ObjectProvider/ObjectView for each independent bound control in your forms. If you share the pair between two bound controls expect them to share data too. You can reuse the same data context for all bound controls.
Again, I apologize for any inconvenience this might have caused you.
Viktor Zhivkov
the Telerik team