c# - DTO's and calls between services -
say have 2 services in service layer, servicea
, serviceb
, each interface (iservicea
, iserviceb
respectively).
the ui layer has reference service interfaces return dtos methods. concrete service classes responsible mapping domain models (ef pocos) dtos.
servicea
takes dependency on iserviceb
via dependency injection using ioc container, in order call methods on service.
there couple of problems arise in doing this:
unnecessary/duplicated mapping , dto call method and/or consume result.
tightly coupling calling method dto contracts of called methods input parameters , return type.
initially thought refactor logic down internal method , call both services. servicea
takes dependency on interface iserviceb
internal methods not exposed.
how go dealing issue?
further information (added example code requested):
// domain model public class customer { public int id { get; set; } public string name { get; set; } } // dto domain model public class customerdto { public string name { get; set; } } // interface servicea public interface iservicea { void addcustomer(); } // servicea public class servicea : iservicea { private readonly iserviceb _serviceb; // servicea takes in iserviceb dependency public servicea(iserviceb serviceb) { _serviceb = serviceb; } public void addcustomer() { var entity = new customer(); // !! key part !! // have map dto in order call method on serviceb. // simple example unnecessary mapping // keeps cropping throughout service layer whenever // want make calls between services. var dto = mapper.createfrom<customerdto>(entity); _serviceb.dosomethingelsewithacustomer(dto); } } // interface serviceb public interface iserviceb { void dosomethingelsewithacustomer(customerdto customer); } // serviceb public class serviceb : iserviceb { public void dosomethingelsewithacustomer(customerdto customer) { // logic here } }
regarding unncessary mapping dtos: consider using data access objects or repositories if prefer domain driven design access database. can have kind of "utility layer" beneath service layer working directly mapped (entity) objects.
regarding kind of coupling: serviceb
implement more 1 interface, 1 visible on server-side. servicea
depend on interface access more internal parts of serviceb
not suitable publication client-side.
Comments
Post a Comment