I understand from other posts that CSLA's 4.5 released version employs the DataPortal_Create with Silverlight in a different fashion than the previous versions. We employ the pattern in which the Create call -- from Silverlight -- would call upon the server-side DataPortal_Create. After installing the 4.5.10 version, we found that the when the Create is initiated from the client (Silverlight), that the DataPortal_Create is not called -- at least not consistently.
In tracking the code, the DataPortal_Create method is found (from within DoCreateAsync) with the proper argument signature (Criteria type):
var method = Server.DataPortalMethodCache.GetCreateMethod(objectType, criteria);
But that method is never called.
What changes are required in CSLA 4.5 to properly continue to use this pattern?
Thanks in advance
I tracked the problem down.... This is something that the CSLA team may want to look into. If one makes a SILVERLIGHT method signature the same as the non-SILVERLIGHT method signature, the SILVERLIGHT method is never called but the non-SILVERLIGHT (server) side will now be called properly as in the versions prior to 4.5.10. It appears that the method cache might be constructed from the client-side methods (Silverlight) even though the server calls the proper method (non-Silverlight). Simply put, the method signature must be present in both versions:
#if !SILVERLIGHT
protected void DataPortal_Create(Criteria crit)
{
// DO A LOT OF STUFF!
}
#else
protected void DataPortal_Creae(Criteria crit){} // DO NOTHING... Just have the method signature for SILVERLIGHT version available
#endif
Ah this is exactly what I ran into as well.
http://forums.lhotka.net/forums/t/11675.aspx
(The original poster may be experiencing a different problem - I just noticed this thread here).
I have the same problem in Silverlight. It turns out you don't need to create a DataPortal_Create(Criteria type) matching your server-side dataportal call. For me it works as long as I just override the default DataPortal_Create() method to remove the [RunLocal] attribute, even if my DataPortal_Create method has parameters. It indeed seems like Csla is defaulting to the default DataPortal_Create (and honoring the RunLocal) if there is no matching signature, instead of going to the server.
Thaaank you Killian35. All you have to do is override the DataPortal_Create() parameterless method to get rid of the RunLocal attribute. You are the gee-ing man. And since I have my own BusinessBase class subclassing the Csla BusinessBase class, I just had to override it once there and the RunLocal is gone for all of my business base descendants:
public abstract class BusinessBase<C, CDto> : Csla.BusinessBase<C>
where C : CslaBases.BusinessBase<C, CDto>
where CDto : class
{
.....
protected override void DataPortal_Create()
{
//THIS GETS RID OF THE DEFAULT RUNLOCAL ATTRIBUTE ON THE CSLA.BUSINESSBASE.
base.DataPortal_Create();
}
...
}
This one had me scratching my groggy head. This has been a very interesting migration.
What has happened here is a "feature not a bug".
In version 4.5 the data portal in Silverlight is now the same as the data portal always has been in .NET. There is now just one data portal implementation.
This does change the rules about how Silverlight interacts with the data portal a little bit, as you have all noted in this thread. These changes make the data portal work the same as it always has in .NET code, so all platforms are now consistent.
Hi Rocky,
For the most part, I agree that it's a feature, not a bug. However, in the case where I have a non-parameterless DP_Create method that only exists in the server-side code (excluded from client-side by preprocessor), Csla, of course, doesn't find the method matching the signature. It then seems to proceed to run the default parameterless DP_Create(with RunLocal), instead of then going to the server with the assumption the non-parameterless DP_Create exists there. And in my case, I use ObjectFactory extensively. So I'd have no matching signatures for anything on the Silverlight side or probably any client side tier.
I would think this is how it would be expected to work with any n-tier system. If I had a web-server that did a DP_Create(with parameters) that didn't have a matching signature on the web-server it would still go to the app server (provided it was an n-tier setup) and succeed or fail there, not utilize the default DP_Create() on the web-server. Now if I called the DP.Create method with no parameters, then I'd expect Csla to deal with the local DP_Create method as it currently does.
In your case I recommend overriding DataPortal_Create in your custom base class to remove the RunLocal attribute. That way you don't need to override it in every class, and you will have changed the default behavior to always do the create on the app server.
That is, btw, the reason for the default DP_Create being RunLocal - so the default do-no-work create operation doesn't round-trip to the server for no reason.
That particular part of the framework's behavior is very much intentional, and this issue isn't unique to SL. Rather, it is only now becoming visible on SL because SL works like .NET now.
I agree that the DataPortal_Create method with no parameters should be left as is. My concern is when I'm making a data portal call with a criteria. I was under the impression that if a DataPortal_Xxx method with a matching signature was not found then the call would fail ,or go to the server if remoting was set up, and try again there.
So I was expecting:
DataPortal.BeginCreate(mycriteria, callback);
to not be affected by:
[RunLocal]DataPortal_Create()
because it does not have a matching signature to my criteria and would either fail or go to the server if remoting was set up.
I noticed that I can add a parameterless [RunLocal]DataPortal_Fetch() to the client side and affect DataPortal.BeginFetch with parameters, the same as BeginCreate. Again, I was under the impression that only a DataPortal_Xxx method with a matching criteria signature would be checked for the RunLocal attribute. And if no matching method was found, then the call would fail or go to the server.
However, this is a very rare occurrence. 99% of the time, the empty create method is all that is needed. So overriding it is no big deal once you learn how things work.
In that regard I think you are correct. If the data portal is somehow mapping Create(x) to DataPortal_Create() instead of DataPortal_Create(x) then that's incorrect.
Copyright (c) Marimer LLC