Changing from Entity Framework to OpenAccess ORM

[lilleliz]

Hi!

I have a project which is nearly finished but we are considering throwing out Entity Framework and using Telerik OpenAccess ORM. My project includes a WCF service. I tried throwing out the old Entity Framework model and created a new one with Telerik OpenAccess ORM. I had to changer some code to change from Entity Framework's Include to using FetchStrategies but other than that I had no apparent problems. However, once I tried testing my WCF Service I had the following problem.

1. Any method that returned a string or otherwise "regular" type of object ran perfectly, even when doing db operations before returning
2. Also if I tried to return a single entity object or list of entity objects without relations it also went well
3. However, when trying to return an entity with relations I got the following error:

An error occurred while receiving the HTTP response to http://localhost:8732/Design_Time_Addresses/WcfServiceLibrary/KemTraxService/. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

Not sure how to proceed from here...

If I can't get this sorted quickly I might just have to leave the Entity Framework in there...

[IT-Als]

Hi lilleliz,

What you are experiencing here might be caused by two things:

1) Does the entity instance you return have a m:n relationship.
If so, the DataContractSerializer that serializes entities over the wire from the WCF service will go on and on forever since it (be default) has no knowledge of object identity. Meaning, if you reference the same object (same object id and class) twice the xml over the wire will represent the same object twice. In a m:n relationship two classes (A and B) will have a list of objects (for class A it will have a list of class B instances and vice versa) residing in each class. Thus, the serializer goes on and on forever by default.

2) The lazy loading is "activated" during serialization
If an Order has a list of OrderLine instances and you go and fetch the Order and return it from your WCF service the serializer will "activate" lazy load of the OrderLine instances, since they where not loaded when the entity (Order) was originally fetched. So basically the serializer traverses the object graph starting from the Order (or whatever type you return) and produces xml for it to be sent over the wire.

However, there is something to do about it.
If your check this thread, there's a solution for case 1) and another for case 2)

In general (at least I think so) it is not a good idea to pass your persistent entities over the wire for the reasons mentioned in the referenced thread. If you don't mind, maybe you should check out the Telerik Data Services way of doing things.

It is all about, detaching the entity from the persistence context (OpenAccessContext) in this case, so the serializer does not invoke the lazy loading.

Just my two pennies,

PS. That being said.. I know Telerik has something coming up with DTO's (detached business objects) that you can use as a DataContract for your WCF service in a later release...
Can someone from Telerik elaborate on this... is it going into the Q3 or later maybe and can it be used to the above scenario? (to me it looks like it can...although depending on how it is implemented)

Regards

Henrik

[Alexander]

Hello Henrik,

Actually our plans are to provide some additional code generation templates which produce transport objects and classes that can translate persistent to transport objects. This would speed up dramatically the development of models like the one used in the N-tier WCF demo. In fact we are already working on those templates and maybe we will be able to provide an initial version by the end of this week. I will update this thread once we have something.

All the best,
Alexander
the Telerik team

[IT-Als]

Great news Alexander,

Really looking forward to this.

One thing is generation of those transport objects... another thing is moving data from the persistent entities and into these objects when returning results to the client and the other way around when applying changes to persistent entities.
Will there be methods to do this mapping?

Can't hardly wait :-)

Regards

Henrik

[Alexander]

Hi Henrik,

I am happy to announce that the templates are done. You can download them and read some details in this article. Please note that this is the first version of the templates, so any suggestions how to improve them are welcome.

Sincerely yours,
Alexander
the Telerik team

[IT-Als]

Hi Alexander,

Great first attempt.. It looks really nice. From the top of my head I can think of the following suggestions to improve:

Navigational properties:
I can see in the code that navigational properties are removed. A nice solution could be to provide "forward only" navigational properties. Meaning: All IList properties are part of the generated DTO...  but the "inverse" property is not a part of the DTO. Example:

Order->OrderDetail persistent classes, where Order has a list of OrderDetail instances and each OrderDetail have a reference back to the Order.
Only the list on Order class needs to be in the DTO and not the reference back.

I think it is very difficult to make "one-size-fits-all" mechanism for DTO generation, since needed information in the DTO might be different from persistent class to persistent class.
I think one possible solution could to "instruct" the template on how to process the generation of the DTO, possible through attributes on the persistent classes. So it is the persistent classes that define how DTOs created from them are processed and generated.

Regards

Henrik

[Alexander]

Hi Henrik,

Thanks for the suggestion. Since the whole metadata model is available in the code generation context, this should not be a problem. I will try to implement that later today or tomorrow and will update this thread.

Best wishes,
Alexander
the Telerik team