public interface IOperationService { IEnumerable<OperationItem> GetItems(int operationId); } public class OperationService: IOperationService { public IEnumerable<OperationItemViewModel> GetItems(int operationId) { var items = getItems(operationId); //дальнейшие действия по преобразованию //OperationItem в OperationItemViewModel } private IEnumerable<OperationItem> getItems(int operatonId) { return _context.Set<OperationItem>().Where(x=>x.OperationId==OperationId) .Include(x=>x.File) .ToList(); } }

Where

  • OperationItem - class of the domain model;
  • OperationItemViewModel - view model

All this code is in my service layer.

I demanded to add a new IAssemblyService service in which currently there will be only one method: IEnumerable<AssemblyViewModel> GetAssemblies(int operationId) and the problem is that for this I need to get a list of the items included in the specified operation and for that I need access to getItems() method from the OperationService . I want to avoid duplication and leave the interface clean. Tell me how best to implement it?

UPD : you can try to do this:

 public IEnumerable<AssemblyViewModel> GetAssemblies(int operationId) { var items = (OperationService)_operationService).getItems(operationId); //дальнейшие действия }

but I'm not sure about this method

  • If you have one service depends on another, then it should be a regular client for a conditionally "third-party" service. - Monk
  • @Monk honestly did not understand at all - Bald
  • As the IOperationService.GetItems(...) is requested from the outside, so your new IAssemblyService must request them. - Monk
  • @Monk so the problem is that getItems & GetItems return different collections: the first one returns DAO instances with navigation properties and other, and the second one is already displayed to the user - Bald
  • If technically this is not one service, then you will have to make the method public and request it from the outside. If one - then do the internal method and use in both services. - Monk

1 answer 1

Template repository is generally one of the most problematic ( one , two , three ...). As a knight at the crossroads you have three ways:

  • Call from one repository to another. But it will turn the code into a web.
  • To be inherited. This will lead to huge god-objects.
  • Change the architecture of the application. On a long-standing project is extremely risky operation.

As you can see, all the options are quite negative: “If you go to the right, you will lose a horse, you will save yourself; go to the left - you will lose yourself, you will save the horse; If you go straight, you will lose yourself and the horse. ”

Perhaps, I would finally recommend that current applications not be changed - but read more about application architectures. Domain Driven, Data Driven, CQRS. It is difficult to recommend books and articles, not knowing what your current level is, but I will try:

  • Thanks a lot for the links. - Bald