Converting from using LocalProxy to remote DataPortalProxy with Web Service

[GreatBarrier86]

Hello, question for anyone that can help me.

Since 2009, we've been using CSLA's LocalProxy implementation. All client/server calls are done on the local computer which directly accesses our SQL database. In order to merge our Xamarin, Web, and Windows code, we'll need to switch over to using a DataPortalProxy.

The issue i have is that we've been using a lot of basic backing fields to hold data (eg: private bool _myValue and nothing else). They have no CSLA backing fields/properties. If i am correct, if i want these fields to move from the server-side (proxy) to the client-side (windows, xamarin, etc...), these will need to be converted to properties with CSLA backing fields.

Is this correct? This appears to be the proper method, but i wanted to confirm before i started trudging through all our code making changes.

Thanks,
Jason

[hurcane]

Have you overridden the default behavior of the local proxy to not clone the business object? If the local proxy is cloning the business object, and your code is currently working, then I believe moving to a remote data portal should be only a configuration change.

If you are not cloning the business object, you could try enabling it and seeing what breaks.

Managed properties without private backing fields is the recommended practice, but you can also use overrides of OnGetState and OnSetState to add your private backing fields into the serialized data stream.

[GreatBarrier86]

I'd prefer to go down the recommended practice line without taking too many liberties. Could cause compatibility issues down the line.

By the way, what benefit is there to cloning vs not cloning the object? That would be good to know just for my knowledge.

[rockfordlhotka]

You can read up on AutoCloneOnUpdate from the past - this became the default back in 2008.

In summary, before version 3.0 CSLA acted differently when using the local vs remote data portal.

When using the local data portal, the logical server-side code used a reference to the object graph, and so any changes to the object graph during persistence directly affected the logical client-side graph. While efficient, this had some serious drawbacks, especially if your transaction failed half-way through persistence, because the object graph would be left in an indeterminate state.

When using the remote data portal, the object graph has always been moved (cloned) over the network from the client to the server. So if your transaction failed half-way through, the client-side object graph was left in a determinate state - as it was before the attempted save operation.

That was just a mess - very confusing, and problematic. So the behavior was changed to have the local data portal also "move" (clone) the object graph from the logical client to the logical server, so the local data portal acts exactly like the remote data portal. Much, much better.

But that was a breaking change of course, so the AutoCloneOnUpdate setting was added so people could choose to use the old behavior if desired - as problematic as it was.

[GreatBarrier86]

Thank you both. Sounds to me like the proper course of action is to keep cloning turned on and convert my private backing fields to CSLA managed properties.

I appreciate the help.

[rockfordlhotka]

I make heavy use of the snippets (like cslaprop) - makes short work of adding property declarations.

[GreatBarrier86]

I just imported them into VS. Thank you very much for that tip.