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?
5 Answers, 1 is accepted
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.
the Telerik team
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
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.
the Telerik team
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.
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,
the Telerik team