i've been spending time reading on solid principles , decided seeing how code base work compares.
in of our code there repository (repository a). when record deleted repository a, need delete associated record repository b. original coder has therefore created dependency concrete implementation of repository b. method in repository within transaction , deletes record repository , calls method on repository b delete associated data.
my understanding of s principle each object should have 1 reason change, repository has 2 reasons change? or way off mark?
repository should have single responsibility - persist 1 kind of entity. e.g. employees. if have delete associated records other repository, looks business logic. e.g.
when employee fired should remove work log
and usual place business logic domain services. service have both repositories , job:
staffservice.fire(employee) implementation like
public class staffservice { private iemployeerepository employeerepository; private iworklogrepository worklogrepository; private iunitofworkfactory uowfactory; // inject dependencies public void fire(employee employee) { using(var uow = uowfactory.sartnew()) { worklogrepository.deletebyemployee(employee.id); employeerepository.delete(employee.id); uow.commit(); } } } so, basic advises
- try keep business logic in 1 place, not spread part of ui, part of repositories, part database (sometimes due performance issues have logic on database side, thats exception)
- never let repositories reference other repositories, repository low-level component of application simple responsibilities
you may wonder if have employee , has nested object stored in different database table. if use object separately employee, above - should have separate repository, , other object (service) manipulates both repositories. if don't use nested object separately employee, employee aggregate root , should have employee repository, query both tables inside.
Comments
Post a Comment