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
@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...
– Rod
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.
– PauloHDSousa