[Solved] Detaching objects from Domain Model

[Jakkie Esschert van den]

Hi,

I've been playing with the 2010 Q2 release of OpenAccess, doing stuff 'the new way' using the visual domain modeler. So far the things I've tried look OK. However, I've now run into an issue I can't solve. Basically what I want is to detach en reattach (merge, in Hibernate terms) objects as described here.

I can't figure out how to do this, and I'm not sure it's even possible. This post suggests it's supposed to be added in the Q2 release, did this feature ever make it to the Q2 release, and if not, when can we expect it?

Thanks.

[Alexander]

Hi Jakkie Esschert van den,

Unfortunately the transport object generation did not make it in Q2. Our current plans for Q3 are to provide code generation templates that will be able to generate such objects along with code that can manage them. In fact we already have an initial version here. Those templates lack some functionality as navigation members but this is only a matter of time.
However, this should give you an idea of what is coming soon and is also a good base to get you feedback. If you think that something can be enhanced, just let us know and we will try to implement it for the next version.

Kind regards,
Alexander
the Telerik team

[Jakkie Esschert van den]

Thanks, I'll check it out.

[Jakkie Esschert van den]

I did some testing, and it looks really nice. I do however run into issues with inheritance, I assume that's not yet supported? 

[Alexander]

Hi Jakkie Esschert van den,

In fact we have not tested the templates with hierarchical models but we will make sure that this is working for the official version. Thanks for pointing that out.

Regards,
Alexander
the Telerik team

[Jakkie Esschert van den]

On the same subject, I've got another issue with those templates. It uses the internal modifier for a lot of functions. This is generally sensible, however I've got a project setup where my model is in a library separate from the webservices. This means I need to call functions like AssembleDTO from a different assembly and I like those functions to be public (or even better, be able to configure the access modifier).

Another minor annoyance, the code generation clears the directory it generates to, which by default is the directory containing the files generated from the model. Opening the rlinq model regenerates those, but this shouldn't be required. 

Ultimately I'd like that directory to be configurable separately. 

[Alexander]

Hello Jakkie Esschert van den,

Thank you again, those are very important points that we should take care of.
The method signatures can be changed from the Includes/Specific.ttinclude file, I believe you will find the exact locations in the file easily. We will have a look at the rest of the problems as well.

Regards,
Alexander
the Telerik team

[Jakkie Esschert van den]

I changed the access modifier locally, works like a charm. 

I ran into another thing I'd like to see changed in the DTO templates. It's a fairly trivial change which I already made locally.  

Currently the AssembleDto function throws a NullReferenceException when null is passed as input. It would be nice to return null when the input is null, that saves me having to check the result of a query form null before calling AssembleDto. And I feel it makes sense to argue that the detached version of null is actually null.

[Alexander]

Hello Jakkie Esschert van den,

You are absolutely right. In fact this has already been changed and you can expect it in the next version of the templates.

Sincerely yours,
Alexander
the Telerik team

[Jakkie Esschert van den]

Greats, thanks a lot.

[Per]

Hi!

I have tried the code template and Im abit concerned.

In many cases you have a seperate project storing your dtos. From what I can see, you need to have the code template in the same project as your rlinq file. This meens that the dtos will be created in the DAL object layer.
To be able to use the dtos from your gui layer, you will need to have a reference in your gui project pointing to your dal layer and this is where things gets abit messy imo.

I think all communication should be routed through a Business Logic Layer, but I see alot of examples where SQL and LINQ i used directly in the OpenAccessDataSource. I think that most people that are using OpenAccess is not using it to create a simple ASP web applikcation with one tire that calls a SQL Express Database, but rather complicated applications where a ORM is needed and I think the examples should reflect thoose senarios. I think the code template should be designed for n-tire applications and that brings me to my questions:

Is it possible to change the code template so its generates dtos in a seperate project and makes the classes public?
Is it possible to change the code template so it generates a business logic layer proxy class that can be used with the build in functionallity of the OpenAccessDataSource?
Is its possible to change the code template so it can traverse objects on insert, update and delete?. ie If I have a Order dto, that object will also have rows, like Order.Rows. If I save this objects, I want both the Order and the Rows to be saved, and that within a "no table lock" transaction ofcource :)

Regards,
Per Bornsjö

[Alexander]

Hi Per,

- Your concern is correct. In fact the latest version of the templates (which will be available with Q3) has some improvements that will let you separate the dto classes in a separate project. Now for each entity you have in the domain model, you will get two classes (files) - a dto and a repository that manages the translation between the dto and the original persistent object. Those classes can be generated in another project, as long as the path (relative or absolute) to the .rlinq file is correct. However, this project will need a reference to the DAL, in order for the repository class to work. So at the moment the only way to separate the dto classes from the DAL is to move them manually to the appropriate project once they are generated.

- At the moment the OpenAccessDataSource can only work with an object scope / context. But we will consider this as a feature request.

 - Navigational members (collections) are already supported by the new templates, and they will behave exactly as you mentioned.

Hope that helps. You can expect the new release in two or three weeks.

Best wishes,
Alexander
the Telerik team

[Per]

Hi!

I just downloaded and installed your new Q3 release to check out the new code generator template and your best practice design guidelines for N-tire developens, in the SDK.

It starts to look better but I'm still missing a few vital (in my opinion) samples.
In the N-Tire samples, you are using a web service layer (wcf) to split the DAL from the GUI. This way new "dto" objects are created in the GUI (see reference.cs file ) automaticly and you dont need a reference between the GUI and the DAL project.
This looks fine but it does not fix the real architectural problem. The dto's are still in the DAL layer :(

When creating a winforms application, you will probobly not be using a web service layer.
Could you please create a sample where you have a DAL, BLL, GUI (Web Application) and a DTO, aka Model, layer (Project), where each layer has its own Namespace?

Regarding the .tt code template:
Could this be changed so instead of using the rlinq classes namespace, when creating the dto and repository classes, it instead uses the namespace of the projects where the .tt file has been added to?

Regards
Per

[Matt.F]

Hi Folks,

I ran into exactly this problem, not wanting the "Dto" classes generating in the DAL class and also not wanting to use WCF in this instance. So, I've modified the sample code files so that they will generate the Dto classes in an external class library.

In theory all you need to do is include a reference to the DAL, the file DefaultTemplate.tt and the folder Include inside your BLL class and it'll generate the DTO & repository classes automagically.
I've made a couple of "enhancements" along the way too, the template will add a reference to the DAL class in the top of the repository classes but not the DTO classes (I didnt figure it was required there). I've also spotted and fixed a confusing feature which was evident in the sample code template, it was generating a public SET property for items which were not then persisted back into the database (eg RentalOrder.Days & RentalOrder.Total). The SET property is still generated however it is now an internal property only. A better way to do this would be to set the values with a class constructor and so away with the set property altogether but, I didnt have time to do this.

Anyhow, hope it works.. I've uploaded the template to the link below.

*Disclaimer* - Please dont blame me if the code template you are about to download causes any kind of damage to your system and / or sanity!

http://www.digitalnervouswreck.com/codetemplate.zip

Matt

[EDIT]

Forgot to mention, you need to edit the path to you .rlinq file in the top of DefaultTemplateCS.tt

[Alexander]

Hi guys,

@Per: I understand our point. In fact those templates are mainly meant to be used on the server side, as shown in the SDK demo. The problem that they solve is that you do not have to use the persistent classes as data contracts and also avoid various problems with serialization due to the lazy loading mechanism or circular references in the model.
You can, however, use the generated transport objects on the client side as well, if you separate them in another assembly (without the repository classes, because they depend on the persistent model). I will add to our TODO list an example demonstrating how to achieve this.
Your suggestion for using the default project namespace is nice and I will add it to the list as well.

@Matt.F: Thanks for your effort to enhance the templates. Your suggestion for setting the readonly properties from the constructor is also valid and we will have it in mind for the next version.

All the best,
Alexander
the Telerik team