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?
Copyright (c) Marimer LLC