Dúvida modelagem

[Thiago de Menezes Cristo]

Boa tarde.

Estou começando a estudar alguns patterns e no livro que estou utilizando como base me deparei com uso de uma classe de serviço para conter a lógica da aplicação:

No caso acima, no meu entendimento, o uso seria algo do tipo (utilizando webforms):

protected void ImageButton_Click(object sender, ImageClickEventArgs e)

{

   var returnOrder = new ReturnOrder() { 

      Action = ReturnAction.FaultyReturn,

      PaymentTransactionId = "ABHF-VKJD-DDJS-ID23",

      PostageCost = 10m,

      PricePaid = 950m,

      ProductId = 87454564,

      QtyBeingReturned = 1

   };

    var returnService = new ReturnService();

    returnService.Process(returnOrder);

}

Esse modelo de ter uma classe de serviço foi utilizado mais de uma vez no livro mas não me agrada muito pois ao meu ver a propria classe ReturnOrder deveria ter o metodo Process unindo dados e comportamento.

Além disso, em uma aplicação grande teria diversas classes com o padrão Entidade/EntidadeServiço.

O que é mais indicado e quais fatores devo levar em conta na hora de criar uma modelagem com esse padrão da classe de serviço?

Livro utilizado: Professional Asp.Net Design Patterns

Abs

Thiago de Menezes Cristo

[edmilson hora]

Thiago, minha opinião sobre as classes services é que eles devem ser utilizados apenas quando algum(ns) metodos não se encaixarem bem em nenhuma classe  do dominio ou é uma operação que possa ser reutilizada por outras classes.

Exemplo:  Tranferencia bancaria,  temos a classe  ContaCorrente 
e uma classe TranferenciaServices.Tranferir(ContaCorrente from, ContaCorrente to)

neste meu exemplo o serviço pareçe cair muito bem pois não é responsabilidade da  conta  fazer a tranferencia entre contas.

espero que outros possa ajudar  com outros pontos de vista.

---

De: Thiago de Menezes Cristo <thiago...@gmail.com>
Para: "dotnetar...@googlegroups.com" <dotnetar...@googlegroups.com>
Enviadas: Segunda-feira, 20 de Maio de 2013 15:25
Assunto: [dotnetarchitects] Dúvida modelagem

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[danielzhe]

Olá!

"Services" não é algo meio anti-pattern? Parece-me anti-OO.

No caso das transferências entre contas, talvez uma classe "AgenciaBancaria" fosse válido.

O que vocês acham?

OBS.: Não sei se isso já foi discutido aqui, pois sou novo na lista e ainda estou lendo as mensagens antigas.

[Marcelo Oliveira]

http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/

2013/5/31 danielzhe <dani...@gmail.com>

[Rodrigo Magalhães dos Santos]

Thiago, bom dia, tudo bem?

Cara, eu já acho que esse padrão de Entidade/EntidadeServiço é o mais apropriado. Sua preocupação em unir dados e comportamento é válida, mas o problema é que muito provavelmente a classe ReturnService não faz uso apenas dos dados de ReturnOrder; ela deve fazer uso de recursos como conexões com BD, acesso a outras entidades, validações envolvendo dados de contexto (como permissões do usuário ativo) e muitas outras. 

A intenção do autor do livro parece ter sido fazer a classe ReturnOrder funcionar como um simples POCO. Veja que ela está perfeita para ser usada como um DataContract num WCF. Se ela concentrasse as atividades que mencionei acima, ela acabaria ficando complexa demais e até violando o Single Responsibility Principle.

Abraços,

Rodrigo.

On Monday, May 20, 2013 3:25:39 PM UTC-3, thiagomcristo wrote: