Persistent objects and scope across multiple tiers

[Roger]

I have a few questions that I can't seem to find answers to in any of the docs or forums.

I have an application with the following tiers:

• Data access:  contains the data provider classes
• Data objects:  contains the persistent data classes
• Business objects:  manages data objects into and out of data access
• Services:  WCF (ws-HTTP) between UI and Business
• UI:  WPF

I am using LInQ-to-SQL with a scope provider and returning the persistent objects up through the layers to the UI, and I have been able to retrieve my data.  The UI displays the data and then allows users to edit it.  If I'm passing a collection, I call the L2S ToList() method on the query and return an IList<T> instance.  Two things I noticed and have questions about:

1. I would have thought that calling the ToList() method would cause OpenAccess to fill the persistent objects, but I can see that they are not filled until the point at which WCF is wrapping the data to be sent to the UI.  Why is this the case, and is there a way to force the data to be filled earlier?
2. Will persistence be maintained across WCF calls?
3. Over successive runs of the application, I seem to be consuming resources that are never released.  Am I right in assuming that this could have something to do with the fact that I am not calling Dispose() on the scope object?  I have tried disposing of the scope object but the problem is that the scope is disposed before OpenAccess tries to fill the persistent objects (as mentioned in #1 above).  How should I manage this?
4. For updating, the examples seem to indicate that I have to select then modify.  But if I'm passing the persistent objects back and forth, can't I simply use them?  If so, can I add a persistent object to the scope object, after beginning a transaction, and expect it to be committed?

I apologize for asking a number of questions in one post but it seems to me that they are intertwined.

[Alexander]

Hi Roger,

As you noticed the objects are not filled with data right away - this is called Lazy loading and its main benefit is saving memory. Large objects are not loaded until they are really needed. Of course you can avoid this and force OpenAccess to load the data at once. In order to achieve this you will need to define an appropriate Fetch plan. More information on how to use fetch plans you can find in this article.

Regarding questions 2,3 and 4, I think the best approach in your case is to use our disconnected API. It is represented by the ObjectContainer class. This class acts just like the ObjectScope but without keeping an open connection to the database.  Steps you will have to do in order to achieve this are:

• Create an ObjectScope and load all needed objects into memory using a Fetch plan;
• Create an ObjectContainer and apply the loaded objects into it and dispose the scope;
• Send the container's content via the service;
• Load the received content into a new ObjectContainer on the UI side;
• Work with objects from the container as you work within regular ObjectScope (the API is the same);
• Send the container's content back to the service and apply it to a new ObjectScope on the server;

A sample application demonstrating how to work with the ObjectContainer class can be found here at our Code Library. I hope this gives some answers to your questions.

All the best,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Roger]

Thanks very much for your response, Alexander.  I had overlooked the ObjectContainer, and that article on fetch plans was definitely better than the help content on the subject.

The main issue I have with the ObjectContainer approach, though, is separation of concerns:  I didn't want to have to include any Telerik or data libraries in my WPF project.  When using the connected API, the objects appear to the UI as part of the WFC service's namespace (in my scenario, Services tier only has access to the Business objects and Data objects, not to Data access).

To mitigate the concern I have, I will try a modified approach to the disconnected API:  the Business objects will act as the transfer point to/from ObjectContainer instances.  Do you see any problems with this approach?  Or does that completely defeat the purpose of the disconnected API?  And how well does this work for an object hierarchy?

[Alexander]

Hi Roger,

In this case you should better use additional middle-level objects that you can transfer over the service and not use the Disconnected API at all. We are preparing a WCF N-tier example application that completely matches your case. The example will be available for download until the end of the next week, so stay tuned. I will notify you once it is published.

All the best,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Roger]

Thanks, Alexander, you guys are awesome!  I'm looking forward to the example application.

[Alexander]

Hi Roger,

The demo application is ready and uploaded. Please read the related Knowledge base article first. It describes how to run the project and contains a link to the source code.

Regards,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.