Business object design question

mselis posted on Wednesday, January 10, 2007

Our functional analysts have designed the 'Life' of a Person as a separate domain object called 'Period'.  They did this because -according to them- a person's life is like any other period:  it has a start and an end.  It also has the same business rules applied to it:

• The start is required.
• The end is optional.
• If the end is known then it should be greater then the start.

They really would like me to do the technical implementation of the business classes the same way.  Something like this:

    public class Period

    {

        private DateTime _start;

        private DateTime? _end;

 

 

        public DateTime Start

        {

            get { return _start; }

            set { _start = value; }

        }

 

        public DateTime? End

        {

            get { return _end; }

            set { _end = value; }

        }

    }

 

    public class Person

    {

        private Period _life = new Period();

 

        public DateTime DateOfBirth

        {

            get { return _life.Start; }

            set { _life.Start = value; }

        }

 

        public DateTime? DateOfDeath

        {

            get { return _life.End; }

 

            set { _life.End = value; }

        }

    }

I’m really sceptical about this; because the Life of a person does not exist on itself, it has no Id to identify it and more important: I think it would make things more difficult, because in the UI the validation errors should appear next to the DateOfBirth and DateOfDeath fields of the Person, which means I have to put the validation rules in the Person class also.

My idea is to forget all about the Period class in the technical implementation and add the business logic that applies to the period directly in the Person class.

Do you guys have any advice on this?

Thanks in advance,

Marc

ajj3085 replied on Wednesday, January 10, 2007

Actually that seems like an ok design to me, if Periods will be showing up elsewhere and WILL always have the same behavior (of which rules are a part).


An alternative would be to have a PeriodRules class, which can check and two dates... but then you have to remember to add the rule in every class that needs it vs. having a seperate class which worries about it.

mselis replied on Wednesday, January 10, 2007

Thanks for your quick reply...

If the design is ok, how do you solve the problem of showing the broken Period rules in the UI then?

I'm seeing 2 possible options:

• expose the Life property (returning a Period) of a Person to the UI, and databind the DateOfBirth and DateOfDeath controls to the Period's Begin and End properties.  This has the advantage that the BL will only be executed once.
• adding the same rules in the Person class to the DateOfBirth and DateOfDeath fields.  This has the advantage that the field names in the eror messages reflect the correct fieldnames of the Person class, and not those of the Period class.

I'm fairly new to CSLA.NET, so I don't know what are considered the 'best practices' in cases like this...  Maybe there is even a third option I didn't think of?

Thanks,

Marc

 

ajj3085 replied on Thursday, January 11, 2007

Ahh, good point.  You'll have to keep Period public then.  You then create a binding source just for the Period object, and bind your two date controls to that.  You then set the bindingsource's DataSource to the LifeSpan property of the root object.  Finally, you'll need a second error provider, and set it to the binding source for the period.

I've done this, and it works.

HTH
Andy

DansDreams replied on Thursday, January 11, 2007

I've done the same thing with addresses.  To me, the whole concept is very powerful if you make the Period a very basic business object in its own right, and then make a self-contained user control that edits Periods.  By self-contained I mean it has its own BindingSource and error provider as well as the input controls.  The control or form hosting the Period user control just needs to handle setting its BindingSource.

Now you just plunk down that user control on any form or control that edits a business object with a Period property.