I'm porting code from an old system to .NET/LLBLGen. We have several database fields whose data is stored as right-justified strings. So we have code all over the place that right-justifies the data (pads with leading spaces) before setting the database field.

I was thinking a better solution would be to have the "set" property of an Entity field do the justification. That way we only have to write the code once.

So how would you recommend changing a "set" property? I could change the generated code, but that would get wiped out every time I regenerate the code.

Option one: Add a partial class file add a new property that sets the original property. In your code set use the new property instead of the original one.

Option two: Use a Validator class. You can validate and modify the value of the field when the field is set (ValidateFieldValue) Or you can Validate or modify the value when saving (ValidateEntityBeforeSave) For more details please check Validation

Thanks for the suggestions.

Walaa wrote:

Option one: Add a partial class file add a new property that sets the original property. In your code set use the new property instead of the original one.

I suppose that would work if the other programmers actually see the new property and use it.

Walaa wrote:

Option two: Use a Validator class. You can validate and modify the value of the field when the field is set (ValidateFieldValue) Or you can Validate or modify the value when saving (ValidateEntityBeforeSave) For more details please check Validation

I like this idea better. I don't have to rely on the programmer to do anything special when setting a property like he would with your first idea. I was going to make a validator class anyways, so it's not like I'm doing a lot of extra work. However, it seems odd to have validation code changing the data.

Thanks again.

clint wrote:

Walaa wrote:

Option one: Add a partial class file add a new property that sets the original property. In your code set use the new property instead of the original one.

I suppose that would work if the other programmers actually see the new property and use it.

Fair enough.

Walaa wrote:

Option two: Use a Validator class. You can validate and modify the value of the field when the field is set (ValidateFieldValue) Or you can Validate or modify the value when saving (ValidateEntityBeforeSave) For more details please check Validation

I like this idea better. I don't have to rely on the programmer to do anything special when setting a property like he would with your first idea. I was going to make a validator class anyways, so it's not like I'm doing a lot of extra work. However, it seems odd to have validation code changing the data.
It indeed works. Yes, it's kind of odd putting it into a validation code, but it also makes sense.

Additional to what Walaa suggested, you have a third option: PreProcess the value to be set. This can be done in a partial class as well:

using SD.LLBLGen.Pro.ORMSupportClasses;

namespace NW.LLBL.MSSQL.Adapter.v31.EntityClasses
{   
    public partial class CustomerEntity
    {
        protected override void PreProcessValueToSet(IEntityField2 fieldToSet, ref object valueToSet)
        {
            base.PreProcessValueToSet(fieldToSet, ref valueToSet);

            // right align the value with a 40 pad
            if (fieldToSet.FieldIndex == ((int)CustomerFieldIndex.CompanyName))
            {
                valueToSet = ((string)valueToSet).PadLeft(40);
            }
        }
    }
}

This is a test of that:

[TestMethod]
public void CompanyNameShouldBeLeftPadded()
{
    var customer = new CustomerEntity();
    customer.CompanyName = "ABC";

    Assert.AreEqual(40, customer.CompanyName.Length);
    Assert.AreEqual("ABC".PadLeft(40), customer.CompanyName);
}

daelmo wrote:

Additional to what Walaa suggested, you have a third option: PreProcess the value to be set. This can be done in a partial class as well

Thanks daelmo. I think I like your idea the best. Conceptually to me it seems wrong for a validation routine to change data. It seems like it should only validate data, not change it.

Actually, I tried having the Validator change the data and it didn't work. I never got around to finding out why. I don't think I'll bother now since this PreProcess idea sounds even better.

clint wrote:

Actually, I tried having the Validator change the data and it didn't work. I never got around to finding out why. I don't think I'll bother now since this PreProcess idea sounds even better.

Validation workaround should work indeed. Anyway good you have how to move on with PreProcess. If you need further help on this just let us know