Child references and service Pattern

Asked

Viewed 145 times

5

A widely used Pattern in DDD, is the service pattern.

My question is, where is the logic for references "daughters"?

For example, a use case, Pedido who owns Produtos

public class Pedido 
{
  public int Id {get;set;}
  public int ClienteId {get;set;}
  public Cliente Cliente {get;set;}
  public ICollection<PedidoProduto> Produtos {get;set;}
}

public class PedidoProduto
{
  public int Id {get;set;}
  public int PedidoId {get;set;}
  public int ProdutoId {Get;set;}

  public Pedido Pedido {get;set;}
  public Produto Produto {get;set;}
}

Let’s go to a Controller Action

public ActionResult Create(Pedido model, int[] Produtos) 
{
   //Lógica...
}

Well... the logic of manipulating the order and its Products, goes within the PedidoService, soon leaving only mine Controller dependency with only 1 Service, and within the PedidoService be dependent on PedidoRepository and ProdutoRepository, or there is a need to create 2 Service and do the Controller be dependent on the 2 Service?

  • Excellent question. Since the answer is long, coming home I will respond calmly, but basically, your controller should only be dependent on Pedidoservice or any other class that contains the business rules, you have to imagine the action of creating a request as an atomic action. In this way, your unit test will be easier to emulate more than one scenario.

  • @wryel will be waiting..: ) It’s just that many talk about coupling, and that DDD "solves" some cases...using DI for example, but here’s the thing... When we work with models, which contain many links (Icollection), who should have greater coupling? the controller with several services? Or a service with multiple Restpository? rsrs...

  • When I had this "problem", I created several services in the controller, I don’t know if it is the best mode, but it worked well. let’s see what @wryel suggests.

2 answers

1

The scenario you present is a scenario of a Aggregate, then logic should always be called from the Service Order service has access to your items. And it doesn’t make much sense that you can call the order items separately from the order.

0

Good question. The responsible for the heavy part of the logic must be the Service, the idea of the Service Pattern is to group a set of operations of a given context and make them available through its interface to the client layers, in this case it must have N Repository. Imagine an application that should be consumed in different ways, such as a REST and Socket service, for example, Services would offer in their interfaces the operations of the application so that the clients (REST and Socket) would address issues relevant to their protocol.

Take a look here

Browser other questions tagged

You are not signed in. Login or sign up in order to post.