Question

Even many Q/A on the subject, I didn’t find a clear answer for this question:

What’s the best design practice for adding business rules (i.e, validations) to entity classes.

I simply want to check some validations before setting the underlying entity value:

public Property
{
    get { return base.Property; }
    set
    {
       // Do some validations or other business logic
       base.Property = value;
    }
}

It doesn’t make sense to create a new class from scratch in BLL when all properties are already there in entity class. On the other hand, entity classes need to be extended with business logic rules.

Using interface need extra work, because a change in DAL (entity) would be reflected in both interface and BLL class.

I’m not sure if inheriting from entity class and overriding it’s properties and adding extra properties and methods is a good idea or not.

A sample pseudo code in more helpful to me.

Thanks

Answer 1

Check out your EF designer-generated code.

Each property Property is actually implemented like this:

    public global::System.String Property
    {
        get
        {
            return _Property;
        }
        set
        {
            OnPropertyChanging(value);
            ReportPropertyChanging("Property");
            _Property = StructuralObject.SetValidValue(value, false);
            ReportPropertyChanged("Property");
            OnPropertyChanged();
        }
    }
    private global::System.String _Property;
    partial void OnPropertyChanging(global::System.String value);
    partial void OnPropertyChanged();

The partial method On-Property-Changing is where you can do single-property validation or business logic.