OpenORM in complex scenarios

Thread is closed for posting
2 posts, 0 answers
  1. Menashay
    Menashay avatar
    8 posts
    Member since:
    Jul 2012

    Posted 26 Feb 2013 Link to this post

    I fail to see the advantages of OpenORM in complex scenarios over
    The examples that I saw always involved one database and pretty much a one-to-one mapping between entities and tables. Even than with n-tier architecture, you still need to create business classes and then map your entity objects to your business objects, and then to DTOs.
    It appears that the only advantage here is the automatic creation of CRUD operations. This automation however falls short when you have complex scenarios such as data that is distributed across multiple databases or even when you have multiple joined tables within a one database. It seems that in those scenarios you only save the ADO calls to [typically] stored procedures and perhaps the mappings of the SQL parameters.

    What am I missing?

  2. Ivailo
    Ivailo avatar
    318 posts

    Posted 04 Mar 2013 Link to this post

    Hello Menashay,

    You are correct that the largest  development time optimization you have with Telerik OpenAccess ORM is in simple to moderate scenarios. However there are also features helping you in more complex N-Tier scenarios which should also be considered, such as:

    1) Our code generation capabilities are useful not only in the Visual Designer. The Add OpenAccess Service wizard offers generation of Web API and various kinds of WCF services which also speeds up your development. 

    2) The DTOs in particular can automatically be created by the Add OpenAccess Service wizard together with a WCF Plain Service exposing those entities. If not needed, the service can always be deleted leaving the generated DTOs for any purpose you would like to use them.

    3) You can manipulate multiple databases during runtime, using separate models and connection strings. We even have some features that can help data synchronization such as our key generators on the client side. In addition, the Attach/Detach functionality allows you to pass entire object graphs between layers in an optimized manner.

    4) The OpenAccess runtime capabilities should not be underestimated - you have LINQ support, caching (both first and second level including MSMQ synchronization), concurrency control mechanisms, dynamic types definition with Artificial Types and Artificial Properties, all that embedded in the product. All of them require a lot of coding for full implementation using ADO.NET.

    In general, OpenAccess ORM is becoming more and more useful for N-Tier scenarios so for each case where you find it falling short in functionality, we are willing to help you with advises and to seriously consider implementing new features in that direction.

    Kind regards,
    the Telerik team
    OpenAccess ORM Q1 2013 is out featuring Multi-Diagrams, Persistent Data Stream Support and much more. Sign up for a free webinar to see all the new stuff in action.
Back to Top