Object Design Question - Encapsulate or Not?

DougZ posted on Sunday, December 17, 2006

I am working on a system for recruiting employees.  I have a read-only Recruit object that has data about a person (name, birthdate, etc.).  Its data is retrieved from tbl_Recruit.  I also have an editable JobInterest object, which represents someone indicating they are interested in applying for a job.  Some of its data is in tbl_JobInterest (how they heard about job, date submitted, etc.) and some is in tbl_Recruit (name, birthdate, etc.).  Tbl_Recruit has a one-to-many relationship with tbl_JobInterest because a particular person could indicate more than once that they are interested in applying for a job.  I was planning on making those objects completely separate.  That would make it so that I would have to code their common properties and methods twice.  Is this the best route to take, or should I encapsulate a Recruit object in my JobInterest class, or should I use some type of inheritance?  Let me know if you need some more info.

Thanks,
DougZ

RockfordLhotka replied on Sunday, December 17, 2006

The answer depends on your use case - on the responsibility of the JobInterest object in that use case.

My guess, based on what you've indicated thus far, is that you should have a JobInterest object that includes some read-only properties with the recruit data, and read-write properties for the other data.

Trying to reuse property declarations is (imo) incorrect. There's no problem having multiple objects that have the same properties, as long as you don't duplicate any rules associated with those properties. CSLA .NET helps you normalize that behavior (the rules) through the rule method concept.

SonOfPirate replied on Sunday, December 17, 2006

Based on the limited information available, it sounds to me like this is more of a parent-child relationship than inheritance or composition.  You mentioned that your DB entities have a one-to-many relationship, and applying some intuitive assumptions about what you are doing, it seems that you would have a Recruit object with a child collection of that recruit's job interests.

I have developed a similar application and we end up with a similar object model to what Rocky created for the ProjectTracker application in the book.  Our primary objects are Recruit and Position (aka Job).  The Recruit object has a RecruitInterests child collection (of RecruitInterest objects) and the Position object has a PositionInterests child collection (of PositionInterest objects).  Both RecruitInterest and PositionInterest derive from our base (abstract) Interest object.  An Interest references the Recruit and the Position.

This allows us to display a list of positions that the recruit is interested in (for the recruit, perhaps) as well as a list of recuits interested in a particular position (for the HR person, perhaps).

I'll defer to the ProjectTracker sample for more details.  Just exchange Recruit for Project and Interest for Resource - for example.

HTH

 

DougZ replied on Monday, December 18, 2006

In the beginning, I made some of the same assumptions about the relationship.  After fleshing out the use cases, though, I found out that the system didn't need a collection of job interests associated with a recruit.  We want to hide the normalization of recruit and job interest data from the user as much as possible.  This is because users don't really deal with "recruits" in their processes.  They deal with job interests and applicants.

Thanks,
DougZ

DougZ replied on Monday, December 18, 2006

Rocky,

I think my use case requires something different than what you're suggesting.  When a job interest is being entered, the user first checks to see if this particular person is already listed as a recruit in the system by browsing a recruit list.  If the person is in the system, the user clicks on the recruit's record in the list, and the form for adding/editing a job interest appears.  In this case, the personal information (name, birthdate, etc.) is already populated by the recruit data, but the user can choose to edit that data in addition to supplying the additional data required for a job interest - all on the same form.  If the person is not in the system, the user clicks an Add New button and must enter all data.  The job interest business object ends up saving some data to tbl_Recruit and some data to tbl_JobInterest.  This is because our users never enter or manipulate recruit data by itself - only when adding/editing job interest objects or applicant objects.  Recruit objects are read-only. 

So, my first idea was to have multiple objects with the same properties, as you mentioned.  However, I got to thinking that I could normalize the assignment of rules and authorization to properties by creating an internally scoped editable-root Recruit object.  The Job Interest object would encapsulate an instance of the Recruit object (myRecruit).  For properties such as FirstName, the Job Interest object would get/set the value of myRecruit.FirstName instead of a local _firstName field.  The Applicant object would have the same relationship to Recruit as the Job Interest object would.  So, the authorization and rules of Job Interest and Applicant would be normalized.

What I originally wanted to know was whether or not it would work, but I'm beginning to think it would be more trouble than it is worth even if it did work.  It would be easier to make sure my rules and authorization for the objects agreed with each other than to code another editable root object.

Thanks for helping me think it through,

DougZ