Architecture for business functions impacting several Dataobjects/database tables

by Matt Baech   Last Updated September 11, 2019 21:05 PM

I am trying to create an example project Web API to see how "clean" I can remake the Delphi(Pascal) API we are developing on my job.

I have created a solution which as of now contains 3 different projects.

  • WebApi (the main interface to the application logic)
  • ObjectLibrary (Models)
  • DataAccess (Repository style data access layer)

If I want to keep my business logic as seperate as possible where should I put following logic?

  • I have a person which can exist with or without an employment.
  • A person can have 0..n Employment
  • When a person is employed it can affect other business objects, such as his OvertimeAccount, VacationAccout etc.which would need to be created and maintained throughout his employment.

I Could use a PersonDataController of some sort, but this would leave me with a DataController which would need to be tightly coupled to objects Person, Employment, VacationAccount - furthermore this would mean that my PersonRepository would also be dependant on my EmploymentRepository and possibly others.

Another approach (and possibly the most straightforward) is to keep business logic in the DataObject Person so I could call Person.Hire(); Which makes the most sense to me, but the issue remains that my Hire function needs to be dependant on the employment object and that my PersonRepository would be dependant on my EmploymentRepository.

Question

Where would I put the business function Hire(Person) in a way that avoids tightly coupling my data objects and repositories?

Tags : c# design web-api


Related Questions