I have been using CSLA 2.1.3 for years and love it (of course). I'm looking into upgrading to the latest 4.0.1 to take advantage of all the improvements. In doing this, I'm reading the C# 2008 book based on 3.6.0. Obviously changes have been made from 3.6.0 to 4.0.1 but...
CSLA 4.0.1 does not have a BusinessPrincipalBase class, but the CslaPrincipal.OnGetState and OnSetState use "BusinessPrincipalBase.Identity" as an argument to AddValue and GetValue method calls. Is this correct? I admit I haven't tested anything, but I don't see how it can be valid if the class doesn't exist in this version of CSLA.
BusinessPrincipalBase is also mentioned in a couple of method comments - in ApplicationContext.cs, CslaIdentity.cs and CslaIdentity.partial.cs.
It's been renamed to Csla.Security.CslaPrincipal
So are the calls to GetValue and SetValue passing a string with BusinessPrincipalBase.Identity correct? Or should that string be changed to CslaPrincipal.Identity?
In CSLA 4 there is now CslaPrincipal and CslaIdentity, and they are designed to work together. There's also CslaIdentityBase if you need to create a custom identity with extra information beyond the standard IIdentity stuff. But even CslaIdentityBase is designed to work with CslaPrincipal.
The big thing is that CslaPrincipal assumes the CslaIdentityBase/CslaIdentity contains the user's information and the user's roles.
So in the simple case, a login is simply a matter of using the data portal to fetch a CslaIdentity, providing the appropriate server-side data access code. In the more complex case you create a subclass of CslaIdentityBase to add your extra managed properties.
Thank you for both of your responses. And Rocky, I understand your explanation which you also explain well in your book (which I have purchased several versions of - VB and C#). I read through this section today. I would not waste you time on a question I could dig out of your book.
My actual question is still not answered. I'm wondering if, when BusinessPrincipalBase was renamed to CslaPrincipal for version 4 did the CslaPrincipal.OnGetState and OnSetState methods accidentally not get changed? The code download for CSLA 4.0.1 has the following code in the CslaPrincipal class:
protected override void OnGetState(Csla.Serialization.Mobile.SerializationInfo info, Csla.Core.StateMode mode)
{
info.AddValue("BusinessPrincipalBase.Identity", MobileFormatter.Serialize(_identity));
base.OnGetState(info, mode);
}
protected override void OnSetState(Csla.Serialization.Mobile.SerializationInfo info, Csla.Core.StateMode mode)
{
base.OnSetState(info, mode);
_identity = (IIdentity)MobileFormatter.Deserialize(info.GetValue<byte[]>("BusinessPrincipalBase.Identity"));
}
Since BusinessPrincipalBase was renamed to CslaPrincipal in 4.0.1, and since BusinessPrincipalBase doesn't exist anymore, should these functions now be the following?:
protected override void OnGetState(Csla.Serialization.Mobile.SerializationInfo info, Csla.Core.StateMode mode)
{
info.AddValue("CslaPrincipal.Identity", MobileFormatter.Serialize(_identity));
base.OnGetState(info, mode);
}
protected override void OnSetState(Csla.Serialization.Mobile.SerializationInfo info, Csla.Core.StateMode mode)
{
base.OnSetState(info, mode);
_identity = (IIdentity)MobileFormatter.Deserialize(info.GetValue<byte[]>("CslaPrincipal.Identity"));
}
The code changed is the argument to AddValue and GetValue ----> I changed the string "BusinessPrincipalBase.Identity" to "CslaPrincipal.Identity".
Thank you for your time.
I see what you are saying. That's arguably a bug, but not something that will actually cause an issue.
The name used for serialization/deserialization doesn't matter - it is arbitrary - as long as the same name is used for serialization and deserialization. So the code works fine because the names match, but the human-readability is reduced.
I'll add this as a bug.
Sounds good. Maybe instead of a bug you can tack it on as an extension of the enhancement to renaming that class! It sounds better that way. If you do a search for BusinessPrincipalBase you'll find it mentioned in a few method comments as well. So you might want to change those just to keep the code base clean and current.
As always, thanks for CSLA.
I appreciate you wanting to make it sound better :)
I've developed a system for tracking issues over time though.
Gotta have rules :)
Copyright (c) Marimer LLC