I'm playing with an idea that when executing something server-side (from logical point of view) I generally do not want and do not need to have csla to clone the objects.
For example, you can have command doing some updates on a large set of business objects.
I have two main reasons for that:
So, what do you think about this idea? Can I suppress the AutoCloneOnUpdate behavior when executing at server-side (logical location) by default.
It seems to me it should be always safe because the main reason for autoclone is to have separated object on the server from the client, because the server could change (and in most situations it does) the object while saving to DB (for example change timestamps, set id when inserting object) and when the transaction during that save fails it should leave the object at client intact.
I assume that server-side executions are always about doing some stuff that never wants to recover from "broken" object. Mostly you want to recover from that by rethrowing the exception that happend and having the client deal with that exception and reexecuting the server operation again.
Hi,
Are you using a N-Tier deployment with a remote DataPortal?
The AutoCloneOnUpdate is to make that you get the same behavior when running in-process (local dataportal) as you do when using a remote portal.
A remote portal will always return a new object from the server - but when your code runs in-process and AutoCloneOnUpdate is false - then your object structure would be as it was when the exception occured (= broken) and you can NOT call Save again on that object.
That is assuming that your save uses a transaction and rolled back in the database - but your object is NOT rolled back to it's initial state!!
Hi,
I'm using diffrent deployments in different solutions.
You have slightly missed what I really want to achieve. I'm aware of N-tier deployment and how the dataportal in that situation work. So I have proposed the idea if it is right or if I'm not wrong with that idea.
When you are logically on server and you are calling your business object to perform Save you don't need to do clones (AutoCloneOnUpdate = true), because you are already on server and you already have the clone on the server. And when you are on the server then calling dataportal on the server calls in most situations local dataportal (or if you have another remote portal then you get the clone but this is not the case you have to worry about).
So what do you think? Is it clearer now for you?
I'm providing code snippet from what I've done in Csla source code to realize and test the idea:
/// <summary> /// Gets a value indicating whether objects should be /// automatically cloned by the data portal Update() /// method when using a local data portal configuration. /// Defaults to <c>true</c>. /// </summary> public static bool AutoCloneOnUpdate { get { bool result = true; #if !SILVERLIGHT && !NETFX_CORE // Miroslav Galajda 10.04.2013 - when executing on server-side (from logical point of view) then clone is redundant if (LogicalExecutionLocation == LogicalExecutionLocations.Server && AutoCloneOnUpdateClientOnly) return false; string setting = ConfigurationManager.AppSettings["CslaAutoCloneOnUpdate"]; if (!string.IsNullOrEmpty(setting)) result = bool.Parse(setting); #endif return result; } }
Where as you can see there is also way to have turn this behavior off through the AutoCloneOnUpdateClientOnly property (appSettings variable).
Does anyone has something against it or is there any pitfall?
Copyright (c) Marimer LLC