Are Objectviews Still relevant?

4 posts, 0 answers
  1. kieron
    kieron avatar
    9 posts
    Member since:
    Dec 2010

    Posted 22 Mar 2012 Link to this post

    I have been using Openaccess for a while now, i use bindingsources for binding data to all my controls etc. but i see thers the objectview which inherits from the binding source. In the documentation the objectview isonly mentioned in the "old api" section, and i can find hardly any new mention of using the objectview on the forums etc. so with the latest domain context system is the objectview redundant? or should i switch from using bindingsources to objectviews? if so whats the difference /benefit?
  2. Viktor Zhivkov
    Admin
    Viktor Zhivkov avatar
    291 posts

    Posted 27 Mar 2012 Link to this post

    Hi Kieron,

    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.
    Lastly we do not consider ObjectView/ObjectProvider pair redundant.

    Don't hesitate to contact us again if you have any other questions.

    Greetings,
    Viktor Zhivkov
    the Telerik team
    Telerik OpenAccess ORM Q1 2012 release is here! Check out what's new or download a free trial >>
  3. DevCraft banner
  4. kieron
    kieron avatar
    9 posts
    Member since:
    Dec 2010

    Posted 27 Mar 2012 Link to this post

    Thanks for that Info that has got me starting using object views. you mentioned sorting and paging just wondering if you can provide examples on that as i cant find anything on how to sort the objectviews results. Also a quick example on filtering would be great as well.

    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?
  5. Viktor Zhivkov
    Admin
    Viktor Zhivkov avatar
    291 posts

    Posted 30 Mar 2012 Link to this post

    Hi kieron,

    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.

    Greetings,
    Viktor Zhivkov
    the Telerik team
    Telerik OpenAccess ORM Q1 2012 release is here! Check out what's new or download a free trial >>
Back to Top