CSLA Business Library

[Art666OTS]

I found an article on CSLA Simple Service Implementation with CSLA.NET and thought what a great mechanism.
I have a web site that uses CSLA and it works fine. I have an updated version of this web site that uses a Business Library as described in the article and it also works fine.
Now I have created an API with the same Business Library but it only partially works. I can read entries from the database but I cannot update/insert them.

When I try to do this the parameters are all set to the default values not the values I have just entered. Below are some code fragments

Code for setting properties

               BusinessLibrary.NOChargeReason ncr = BusinessLibrary.NOChargeReason.New();
                ncr.SCID = 1;
                ncr.EnteredDatTime = DateTime.Now;
                ncr.EnteredBy = "me";
                ncr.Reason = "this";
                if (ncr.IsSavable)
                {
                    ncr = ncr.Save();
                }

Code for setting up parameters for Insert.

     internal void Insert(object parent)
        {
            using (SqlConnection cn = new SqlConnection(DataBase.ApplicationConnection))
            {
                cn.Open();
                using (SqlCommand cm = cn.CreateCommand())
                {
                    cm.CommandText = "NOChargeReason_INSERT";
                    
			cm.Parameters.AddWithValue("@EnteredBy", EnteredBy);
			cm.Parameters.AddWithValue("@EnteredDatTime", (EnteredDatTime.Equals(DateTime.MinValue)) ? Convert.DBNull : EnteredDatTime);
			cm.Parameters.AddWithValue("@Reason", Reason);
			cm.Parameters.AddWithValue("@SCID", SCID);

                    DoInsertUpdate(cm);
                }
                MarkOld();

Sample of the code for a property

        #region Reason
        private static readonly PropertyInfo<String> _ReasonProperty = RegisterProperty<String>(c => c.Reason, "Reason", RelationshipTypes.PrivateField);
        private String _Reason = _ReasonProperty.DefaultValue;
        private String __Reason;
        public String Reason
        {
            get
            {
                return GetProperty(_ReasonProperty, _Reason);
            }
            set
            {
                SetProperty(_ReasonProperty, ref _Reason, value);
            }
        }
        #endregion Reason

Any assistance would be greatly appreciated.

Arthur

[Art666OTS]

I may have missed out on supplying some information above.
The BusinessLibrary is using NuGet CSLA-Core 4.11.2 and the API is using .Net Core 3.1 Console Application.
What is confusing me is that I can retrieve the data from the database, create a new Business Object and assign properties but in the Save the assign to the parameters fails. It appears like an new Business Object.

[rockfordlhotka]

There's an overload to the Save method where you pass a Boolean value to override the default behavior of the operation.

By default, a domain object maintains its own metastate, including the IsNew property. When a new instance is created, IsNew is true, and when an instance is loaded from the database via the data portal fetch operation, IsNew is false.

In a block mode experience (like a web service endpoint, or an MVC postback), you are actually doing an update operation, but the domain object thinks it is "new". The solution is to use the overload of Save to force the operation to be an update, because you know the object isn't really new.

[hurcane]

This seems like it could be a serialization issue. Are you using managed properties? Are you using the binary serialization or the mobile serialization? If you are using mobile serialization and you are not using managed properties, then you must override the OnGetState and OnSetState methods. You can find details on using these methods in book 2 of the Using Csla 4 series.

If that is not it, then I would put breakpoints on the constructor(s) of your class and also on all lines in the class that would change the value of the property you are evaluating. By stopping at each breakpoint and examining the call stack, you can gain an understanding of the overall sequence of the code.

[rockfordlhotka]

I agree with @hurcane - I bet when you updated from CSLA 3.5 that you kept using private backing fields. Which is fine, except that you then need to override OnGetState and OnSetState to manually get/set each property from the serialization stream.

I strongly recommend using managed backing fields with the new property syntax, as that'll let CSLA do the work automatically.

[Art666OTS]

Thanks you both for your replies. My apologizes a sample of a property would have been helpful in the documentation provided.
I do use private backing fields however I looked and the Breaking changes and blogs and saw some things from JohnnyBee about Managed Fields. He seems to be quite prolific so I used his example as a template see example below.

From the above code I think I am using Managed Fields. Also I do not set the CslaSerializationFormatter anywhere so I should be using the default. If what I assumed is true this answers your first paragraph so onto the next one.
I think everything is fine until I reach oh = oh.Save(true); in the BusinessLibrary code. The next line that is hit is the constructor for the object. Note that it is public not private as I used to have in my old Csla code and is recommended in the books.

If I try to make the constructor private the BusinessLibrary will not compile and I get the error in the image below.

So I reverted the code to a public constructor
When at this point the call stack shows that I have executed some external code and am now at the constructor.

So the code appear to be creating a new object which is why the properties do not contain values. Is this what should be happening here or is the setting of the constructor causing the problem?

[hurcane]

Yes, the data portal creates a new object and then it injects the properties. You are using managed properties with backing fields. You are getting partial benefits. You get automatic authorization checks and invocation of business rules. But you don't get automatic serialization of values.

What you are missing out on is automaticaly serialization of property value. With private backing fields, you must still override OnSetState and OnGetState and and include your private backing fields in the methods.

The key to this is on page 32 of book 2, with an example on page 33.

For your property, you would need something like. Plus you need to add a line for each backing field.

protected override void OnGetState( 
	Csla.Serialization.Mobile.SerializationInfo info, Csla.Core.StateMode mode) 
{ 
    info.AddValue("_OHAdrSuburb", _OHAdrSuburb); 
    base.OnGetState(info, mode); 
} 
protected override void OnSetState(
	Csla.Serialization.Mobile.SerializationInfo info, Csla.Core.StateMode mode) 
{ 
	_OHAdrSuburb = info.GetValue<string>("_OHAdrSuburb"); 
	base.OnSetState(info, mode); 
}

For large classes with many properties, this is a big undertaking. Our main code base is still running Csla 3.0. We are in the middle of a long-term project where we are running Csla3 and Csla5 side-by-side, with new work being done in 5, and old work being migrated when the business needs warrant it.

[Art666OTS]

hurcane,

Thanks for your reply. You are spot on. I added the two Overrides and it works as expected.
I note you comment about many properties and many classes. I am lucky in that early on I used a tailor made class builder which I think I got the idea for from Business Objects 2005 by Rockford. I have 167 BO's and 94 views in an SQL database and including adjusting the class builder it took about 2 hours to have all the classes updated. See a sample of the change below which I copied from a blog by Rockford that minimized the lines required.

I cannot say how much I appreciate your assistance in this. Thanks again
Arthur

[Art666OTS]

Re submitted by mistake