Stupid Questions

6 posts, 0 answers
  1. LordRevan007
    LordRevan007 avatar
    20 posts
    Member since:
    May 2011

    Posted 25 May 2011 Link to this post

    Hello to all. I am using the latest version of this open access with postgresql. And I have something unclear. In the help samples(SofiaCarRental) I see that a project with the diagram and the context is created and then other projects consume it.  But in the documentation I see another approach with the ObjectScope. For what I can see the latter one is a little more general than the first one.

    My questions are:
    1.For a 2 tier application(client-server postgresql), which approach should I choose, in terms of good practice and performance?
    2.Can I target my generated classes from the domain diagram to another project(other than the one where is the diagram) in my solution?
  2. PetarP
    Admin
    PetarP avatar
    754 posts

    Posted 25 May 2011 Link to this post

    Hello LordRevan007,

     The diagram you have seen (or the rlinq file as we are referring to it) is our new approach of working with OpenAccess. Since it has been introduced all our efforts are aimed into improving this approach. The other one with the object scope is in maintenance mode meaning that no significant development time will be invested into it (besides fixing crucial bugs).
    1. Having above in mind we are encouraging our new customers to use the new approach as it is better supported and it will be developed further in the future.
    2. Since the diagram generates normal .Net classes, they can be used everywhere across your projects as long as the project you want to use them in has reference to the project they are located in. Here is an example:
    If your persistent classes are in a project called Model, and you have a project called Consumer that has a reference to Model then the classes produced by the diagram that are located in Model will be available in the Consumer project. If you have a second project called Helpers that does not have a reference to the Model project then the persistent classes will not be available there.

    I hope that my answer has been useful to you.

    All the best,
    Petar
    the Telerik team
    Want to use Telerik OpenAccess with SQL Azure? Download the trial version today. 
  3. DevCraft banner
  4. LordRevan007
    LordRevan007 avatar
    20 posts
    Member since:
    May 2011

    Posted 26 May 2011 Link to this post

    Hello, thanks for the response. The reason why I asked the second question, is in fact that I don't know if I need a DAL. From what I see, the project that has your diagram does the following(these are assumptions, so correct me if I am wrong):
    1.Generate persistent classes(in my case this the domain model)
    2.Generate the context(from what I see it is used for persisting the data).

    In this case, I think that the project that has the diagram and does all the "dirty" work sounds like a DAL, so if my persistent classes are my domain model, for referencing them throughout the solution I need to reference the DAL. In this case, the SoC principle I don't know if it is met.

    If I am wrong, please correct me and point where are my mistakes.

    Thanks in advance
    LordRevan007 
  5. PetarP
    Admin
    PetarP avatar
    754 posts

    Posted 31 May 2011 Link to this post

    Hello LordRevan007,

    How you organize your project pretty much depends on the specific scenario you are facing. One of the typical scenarios is to have the so called DAL that is referenced by another project usually referred as a BLL. In this BLL you can implement all the business logic your project requires and reference this BLL in your other projects. In this way the DAL will be referenced only in one place and you will have the so called separation of concerns.

    Kind regards,
    Petar
    the Telerik team
    Want to use Telerik OpenAccess with SQL Azure? Download the trial version today. 
  6. LordRevan007
    LordRevan007 avatar
    20 posts
    Member since:
    May 2011

    Posted 01 Jun 2011 Link to this post

    Hello, thank you for the response, but after reading the documentation for open access orm, I came up to the following conclusion:
    The project in where you put your diagram is actually 2 projects in one. First is the DAL which in this case is represented by the context class. The second is the domain model which is actually represented by the persistent classes that your diagram generates.  There are some solutions for separating the DAL and the domain model represented by the persistent classes. One solution would be the movement of the newly generated classes to another project and changing their namespace. The second one, would be not generating the context in same project as the diagram and generated classes exist, for this one I found this tutorial(http://www.telerik.com/help/openaccess-orm/openaccess-tasks-model-tools-manually-define-context.html).

    I don't know what the impact will be in terms of good practice, but at this point is everything that I got and I will choose the solution that will work for me. I think that would be a nice new feature that you could separate your persistent classes from the context in two different projects.

    LordRevan007
     
  7. PetarP
    Admin
    PetarP avatar
    754 posts

    Posted 06 Jun 2011 Link to this post

    Hi LordRevan007,

     We have actually planned for this feature. While you are able to choose not to generate a context right now, we have extended this functionality further more and we will provide a wizard that will enable you to generate your context in any project you would like based on an rlinq file. This functionality is expected to be out with our next service pack.

    Greetings,
    Petar
    the Telerik team
    Want to use Telerik OpenAccess with SQL Azure? Download the trial version today. 
Back to Top
DevCraft banner