Correct way to handle persistent data? (OA + WCF + WPF)

[Roger]

I've been using OpenAccess for a while but I feel as if I'm using it incorrectly, that I'm perhaps writing way too much code to support it.  So now I'm at the point of either figuring out a better way, or dumping it and going back to standard ADO.NET code.  I am reading as much of the other posts and documentation that I can, but I'm hoping someone out there can help me see the light and give me a more concise answer.

At the moment, I have an n-tier application that will run across two or more physical tiers.  I need WCF services to support remote Windows users and, at some point, web clients.  I'm using WPF for presentation, with ObservableCollection objects as the basis for my data-binding.  My BLL code does a lot of wrapping and unwrapping of OA persistent objects, and separately manages object state.  I use client-side proxy objects to create and manage the ObservableCollection objects, which are implemented using the BLL objects, and those objects are then consumed by the UI.

When I started with OA, my impressions were that:

1. The persistent objects were not persisting across physical boundaries because it appeared that the scope was closing before delivering the data.
2. As a result of #1, I was going to have to write intermediary code to deliver data changes into and out of the OA persistent objects.
3. At the time, I felt that the disconnected persistent container was not going to work because of how I expected to use it in WPF.
4. Creating my own BLL objects was easier because I could combine and manipulate the data elements.

But now the work I'm doing is feeling more and more onerous.  Updating a hierarchy of persistent objects, using my approach #2 above, becomes a real hassle because you have to ensure that all the objects are recreated before adding them to a transaction.  And, of course, I lose the advantages that OA's caching would normally give me.  Given a complex hierarchy, this activity can be painful.

So, my questions are these:

1. Is it worthwhile for me to continue to use OA (presuming I use it the way it was intended)?
2. How can I maintain the SoC across the different layers (i.e. I want only my Data Access layer to contain any references to Telerik libraries)?
3. Is it possible to pass a persistent object from OA to WCF, through SOAP to WPF, and back again, without losing the persistence and tracking mechanisms? Can lazy loading be used in this scenario?
4. If I'm reverse-mapping, can I combine more than one table into a single data entity?

Thanks.

[Alexander]

Hello Roger,

Your impressions so far seem correct. Currently the best approach is to use wrapper classes as you did. Besides the strong SoC, the two major issues that are avoided this way are:
1. WCF tries to load the whole object graph when an object is to be sent. As the lazy loading of the persistent objects cannot be switched off, copying just the necessary data to a proxy object and sending it through the service resolves the problem. Unfortunately this requires some additional code to be written.
2. If a persistent object is serialized, it is no longer connected to an object scope and both the lazy loading and change tracking are lost. As a result, when the object is sent back to the service to persist the changes made by the UI layer, you will have to load the original object and apply the changes from the received one.
Note that the caching mechanism is still working on the server side and if an object has already been loaded, it will not be retrieved from the database again. You can find more information on the supported caching strategies in the following blog posts:
Level one cache
Level two cache
Distributed cache
You can take a look at our N-tier demo application with WCF as well, if you have not found it already.

Another possible approach is to use the ObjectNetworkAttacher helper class which is distributed with Telerik OpenAccess ORM. It enables you to serialize and deserialize persistent object, as well as attaching them back to an object scope. However, there are some requirements for the classes - they should expose public id and version fields or implement the IDataObjectKey interface. This is a relevant approach if you do not want to deal with proxy objects. More information on how to use the ObjectNetworkAttacher could be found in this help topic.

Regarding your last question, I am afraid this is not possible at the moment.

All the best,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[Roger]

Thanks, Alexander; I hadn't see the N-Tier example yet.

I see good value in the ObjectContainer class but I guess I'm a little disappointed that it means having to include the same Telerik libraries across all tiers.  Is there any chance that ObjectContainer might be at least extracted to its own assembly at some point?

[Alexander]

Hi Roger,

Thank you for the suggestion, we have logged it to our product backlog system. However, at this stage we are not able to give you an exact time-frame for implementing it.

Best wishes,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[David]

Hi Alexander,

Any update as to when this might happen?

[Alexander]

Hi David,

We are currently working on features with higher priority which should be implemented for the Q1 release. I am afraid the separation of the ObjectContainer in another assembly will be postponed for Q2 2010 or later.

Kind regards,
Alexander
the Telerik team

Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Follow the status of features or bugs in PITS and vote for them to affect their priority.