How would you design this?

How would you design this?

Old forum URL: forums.lhotka.net/forums/t/4615.aspx


dmo145 posted on Thursday, April 03, 2008

Hi all,

I can't quite get this. I have an app that saves applicants for jobs. A job can have many applicants. Before an applicant is allowed to be added to a job a bunch of things need to be checked on the state of the job. This leads me to think I should have something like:

Job BO - contain the rules governing whether an applicant can be added to itself

JobApplicant Child BO - responsible for saving a valid applicant, regardelss of job.

I'm curious if this makes it to complex in situations where Applicant has its own children. So, should applicant require a child list of resumes (which i think is coming), i'd be left with a grandchild situation which should be really rare (scary). Also, Applicant and Job are saved in different DBs.

So, given that, should I have something like:

Job BO - contain the rules governing whether an application can be added to itself

JobApplicant Child BO - responsible for managing the association of applicant to job

Applicant BO - responsible for saving a valid applicant

This also bothers me since an applicant can never exist without being associated with a job. It also can't be associated with multiple jobs. So JobApplicant seems kinda useless. Because Appplicant requires a job and needs a jobs permission to exist, calling applicant a root seems kinda dumb and misleading. However, this does seem to avoid the complications of the grandchild.

Or (since I'm basically visualizing a screen where the job is already known and user is filling out information about the applicant) should I just have an ApplicantBO thats responsible for figuring out by itself if it can be added to a job? Maybe require a jobID in the constructor and do somthing form there? This way the client never needs to work with the job, just know how to id it.

I think I'm just jamming myself up. This should be obvious. Any advice?

Thanks everyone,

Dane

Copyright (c) Marimer LLC