For my current project we have a set of Entities, Clinic, Patient, Address. we use EF Core, with GenericRepo and Service Pattern
Entities Relation
Entities Relation
As you can see above these are the relations of the entities.
-
Clinic must have an Address
-
Patient must have an Address
-
An Address can actually live on its own (can be searched and added to a clinic for example)
Following this, I was naive and immediately created the following Services:
The First Issue
We realized that the ClinicService
will have to somehow operate both on Clinic
and Address
. For me there are two solutions
Both have problems:
-
if I include the
AddressRepository
then I loose the Business Logic hidden inside theAddressService
-
If I include the
AddressService
then I loose integrity. The Service acts as a UoW so when Creating a new Address, this would be saved in the DB. Then if theClinicService
had any bug further, it would result in an orphan address being created.
Second Issue
To make things more complicated, we have of course, controllers exposing basic CRUD functions. As described above, we can create both a clinic and an address, so we must have the AddressService
and ClinicService
-
Should the
ClinicController
have access toClinicService
andAddressService
? The problem with that is still that each service is a UoW so we would still have potential orphan addresses. Also because we return thoseContracts
think, DummyModels we loose the EF binding if we return anything but the entity from the Service.
In Essence
How do we share business logic? I know in this case we could make a smart AddressClass that does the transformation, but imagine our BusinessLogic requires a DB lookup – Does that PostCode actually exist?
P.S Question has been posted on SO as well https://stackoverflow.com/questions/59693884/sharing-business-logic-between-different-uow-services