Query

4 posts, 0 answers
  1. john
    john avatar
    67 posts
    Member since:
    Jan 2012

    Posted 05 Dec 2012 Link to this post

    I have a web based application as following layser:
    1.DataContext to hold context class and entity class
    2.Service to handle all business logic
    3.Web UI

    My query is as below:
    1.Whether it's neccessary to split the DataContext  as two projects:Entity project and Context project?
    2.Is there any risk if UI to call datacontext class for updating and inserting?
    3.As my understanding, whether only service layer can call datacontext class and UI only call service? The entity is shared for all projects.
    4.I see your links http://www.telerik.com/help/openaccess-orm/dev-guide-web-development-manage-context-overview.html. If I don't dispose the OpenAccessContext object, is there any risk?
    5.For transaction, what's the advantage of OpenAccesORM than System Transaction?
  2. Boris Georgiev
    Admin
    Boris Georgiev avatar
    190 posts

    Posted 10 Dec 2012 Link to this post

    Hi John,

    I will give you overall answer for your questions 1,2 and 3.
    It is not necessary to split Data Access Layer to two projects, you can have one project, which is used only by Business Logic Layer. Then you will not have any issues when using it in the presentation layer.

    You can use DTO layers with the Add OpenAccess Service Wizard. For more information and to see how its implemented, we provide a video and two samples in our SDK:

    - WinForms: Sofia Car Rental - WCF Plain Service with Windows Forms
    - WPF: Sofia Car Rental - WCF Plain Services

    For your 4. question, there is a risk if the OpenAccessContext instance is not disposed when it is not needed. It is a good practice a short living context to be used:

    using (EntitiesModel dbContext = new EntitiesModel())
    {
    ...
    }

    Thus, you will make sure, the context is properly disposed and the underlying connection is closed.

    OpenAccessORM transactions are fully automated with the context. Here you can find more information about them and how you can handle them.

    If any other questions arise, do not hesitate to contact us back.

    Kind regards,
    Boris Georgiev
    the Telerik team
    Telerik OpenAccess ORM Meets ASP.NET Web API. Read more.
  3. DevCraft banner
  4. john
    john avatar
    67 posts
    Member since:
    Jan 2012

    Posted 11 Dec 2012 Link to this post

    For your answer about 1,2 and 3, if only BusinessLogic layer call DataAccess layer which combin DomainContext and Entity, how about if the web application use OpenAccessLinqDataSource control to bind data? In that case, the web UI project will refer DataAccess layer and developer can call methods which are in DataAccess layer.

  5. Boris Georgiev
    Admin
    Boris Georgiev avatar
    190 posts

    Posted 14 Dec 2012 Link to this post

    Hi John,

    If your web application is using OpenAccessLinqDataSource control to bind data, it will need direct access to OpenAccess Domain Context which is located in the data access layer. This will violate the N-Tier application pattern. So if you want to have an application with separated tiers for data access, business logic and Web UI you should not use OpenAccessLinqDataSource. 

    I hope that helps.

    Kind regards,
    Boris Georgiev
    the Telerik team
    Telerik OpenAccess ORM Meets ASP.NET Web API. Read more.
Back to Top