Persisting Extended Classes

2 posts, 0 answers
  1. Nigel
    Nigel avatar
    10 posts
    Member since:
    Jul 2008

    Posted 04 Apr 2010 Link to this post

    Hi, I know I must have missed something obvious here, so I do apologize.

    I have created a base set of classes and interfaces in a DATA class library that defines the interface for a module and provider, but will never be instantiated.

    I have then created another Data.OpenAccess class library where I have created the provider and extended all the classes from the base definition. However most of these classes do not need to do anything more than the base class, however the problem that I have is that when I mark the new class as persistent it says there is no fields to persist. Below is an example:

    namespace GoDat.EntityModule.Data.Base  
    {  
        public class Comment : IComment  
        {  
     
            #region IComment Members  
     
            protected IEntity _Target;  
            public IEntity Target  
            {  
                get  
                {  
                    return _Target;  
                }  
                set  
                {  
                    _Target = value;  
                }  
            }  
     
            public string Author { get; set; }  
     
     
            public string Message { get; set; }  
     
            public DateTime CreationDate { get; set; }  
     
            #endregion  
        }  

    and the class in the OpenAccess Library:
    namespace GoDat.EntityModule.Data.OpenAccess.Data  
    {  
        [Telerik.OpenAccess.Persistent()]  
        public class Comment : GoDat.EntityModule.Data.Base.Comment  
        {  
            public Comment()  
            {  
            }  
        }  

    Have I missed something or will this work only with members defined at the persistent class? If so, what is the recommended method for implimentation of a provider model where some functionality of the classes will be independent of the data source/provider?

    Further, is there some documentation on how best to use OpenAccess as a provider? The problem I come into (and this is pretty much the barrier I have hit every time I think to use OpenAccess in a project) is that I do not want the whole project to know how the data is stored, only work with the data objects in that project. However everything I have read, and everything I have tried requires that a transaction be opened before changing the values of a object. Ideally the way I should be operating with objects in the project is:

    Get the object
    Make changes to the object
    Pass the object back to the Manager calling a save method.

    However, from what I can see, the method would be:
    get the object
    Start a transaction
    Make the Changes
    Commit the transaction

    Which is fine, I can define this to be the interface that all providers must use (SQL, OpenAccess, which ever) however it dosn't give a clear seperation of BL and data storage, particullarly that this transaction will sometimes be needed to be opened and closed in the presentation layer if it makes any changes to the data.

    Or do I need to create a set of objects that will be used through the website (External objects), and a set of objects that will be persistent (Internal Objects).

    If I have missed a documentation on how I should be doing this, sorry, first time I have seriously tried to make OpenAccess work in a real world project using the Provider Model.
  2. Damyan Bogoev
    Admin
    Damyan Bogoev avatar
    581 posts

    Posted 08 Apr 2010 Link to this post

    Hello Nigel,

    The error arises because you have auto-implemented properties within these classes. Currently auto-implemented properties are not supported by the Telerik OpenAccess ORM. You can avoid this error by providing fields which the properties should use.
    We provided to you a sample application which demonstrates how to use the Telerik OpenAccess ORM with business objects. The business objects are independent from the data source.
    I hope you will find the provided information helpful. If any other questions arise please contact us back.

    Sincerely yours,
    Damyan Bogoev
    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.
  3. DevCraft banner
Back to Top