Some business logic in a persistent property setting

[Vitaliy]

I'm currently converting a large old project from the classic model to the newest utility build.

Well, you used partial classes. As the Genome developers did many years ago...
It is a nice looking solution. And it was working fine so far I was converting rather simple classes.

But now I'm working on a complex class. And I have an issue.
There are to many lines of code in the persistent property setters.
How can I reprogram this in the new model?

I have just two ideas:
1. Make a wrapper class of the persistent class. 
2. 'Wrap' the complex property. So, I will specify on the diagram it as AutoGenerated_ContactType with the access modifier as as private.
And will just manually wrap the persistent field with all required logic in the setter.

The (1) is as written in the books solution. :-) But it is too much handmade simple code to wrap every property, even trivial property.
The (2) is acceptable but the fake properties looks ugly in the designer.

Well, the Rational Rose had special sections on the diagram to specify the user's code. You were able to change it in the code editor, because the sections were protected with  pre-compiler sings, so the generator didn't change it. It is a rather unwieldy solution though... 

Do you know any better method? Maybe with an inheritance? I can't understand how to use it? 
I can see the generated properties as virtual...
How did you imagined to use it?

Thank you, thank you.

[Kaloyan Nikolov]

Hi Vitaliy,

You are right those two options are the usual solutions for such problems. 

It is true that option 1 requires a lot of code and in some cases will complicate the other code as at the end in your code you should work with the wrapped class but should add the underlying persistent class to the data context in order to store it. 

I can suggest you the following approaches in addition:
1. You can keep the classes as they are implemented at the moment if you map the using our code only fluent API. This would work well if you don't need the designer. 

2. You can leverage the OnPropertyChanging and OnPropertyChanged events to place your logic instead of adding it in the setters. 

3. You can define partial methods to be executed before and after the actual value is set in the setter. The code would look like this:

private string _full_name;
public virtual string Full_name
{
    get
    {
        return this._full_name;
    }
    set
    {
        Before_FullNameSet(value);
        this._full_name = value;
        After_FullNameSet();
    }
}

protected partial void Before_FullNameSet(string value);
protected partial void After_FullNameSet();

Here you can see I have defined 2 partial methods and they are called in the property setter. To utilize them you should define the body of the method in a partial file for the same class. If the method body is not defined the compiler will remove the method call. With a simple customization in our out-of-the-box code generation templates you can get those methods generated for each property in all classes automatically. For your convenience I have prepared the code generation modifications (see the attached file). This article describes how to proceed with custom code generation, once you copy the templates locally as described in the article you need to replace the attached file and you are done. 

I hope this helps. 

Regards,
Kaloyan Nikolov
Telerik

 

 

[Vitaliy]

Good

the (3) method is not yet elegant but already acceptable! :)

I thought about (2). If I will specify my properties instead of the generated... I guess I won't be able to use them in LINQ, and no chance to assign them to fields like I did in the classic model -  [FieldAlias("....")] ?

[Vitaliy]

I meant my (2):

2. 'Wrap' the complex property. So, I will specify on the diagram it as AutoGenerated_ContactType with the access modifier as asprivate.

[Kaloyan Nikolov]

Hi Vitaliy,

That's true, if you wrap a persistent property in another property (so called transient property) you will not be able to use the wrapper property in Linq statements, they also should not be included in the mapping.


Regards,
Kaloyan Nikolov
Telerik