hlegius wrote:
Então as entidades deverão apenas conter rotinas que cabem a elas mesmo fazerem, como chegar seus próprios dados, comparações de dados recebidos com dados em memória. Serviços trabalham essas entidades. Tratam as informações, fazem checagens - Às vezes usando métodos da própria entidade, às vezes consultando outros Serviços e por fim o Repositório que está lá para buscar entidades persistidas para auxiliar o serviço em algo, ou simplemente para exibi-las ao usuário. Resumão correto ?

Marcio Duran wrote:

sergiotaborda wrote:
O ponto é: Repositorios são mais uteis. entidades podem usar repositorios, mas não é bom poluir a interface da entidade com métodos de pesquisa especializada. Isso é função do repositorio.

Sergio poderia dar maior visibilidade nessa colocação "interface da entidade com método de pesquisa", a quem você esta atribuindo pesquisa, um façade "não entendi"

hlegius wrote:

sergiotaborda wrote:Eu preciso de 2 coisas além do objeto Pedido. Um objeto que saiba criar pedidos e um objeto que saiba procurar pedidos.
O segundo é um repositorio de pedidos. O primeiro é um Serviço.

Certo. Então o cara que aplica regras de negócio é o Serviço da entidade. Ele executa alguma tarefa - algum "serviço" - e pronto. Certo. O serviço pode comunicar-se com seu Repositório para persistir alguma informação tranquilamente, correto ?

sergiotaborda wrote:Isso será feito pelo ServiçoDeVerificaçãoDeVenda ou algo assim. Depois disso o pedido muda de estado.

Esse suposto "serviço" irá pegar o número do cartão, conectar-se à um webservice e validar a compra, ao tentar mudar o "estado" do pedido ele deverá solicitar a mudança ao ServiçoPedido (algo que seria o mais correto [centralizar coisas]) ao invés dele mesmo(ServiçoDeVerificaçãodeVenda)

sergiotaborda wrote:O seu modelo básicamente mostra entidades e repositorios ( embora vc os chame de serviços, eles não são serviços realmente). métodos como "registraCompra" terão que ser colocados como serviços.

Então as entidades deverão apenas conter rotinas que cabem a elas mesmo fazerem, como chegar seus próprios dados, comparações de dados recebidos com dados em memória. Serviços trabalham essas entidades. Tratam as informações, fazem checagens - Às vezes usando métodos da própria entidade, às vezes consultando outros Serviços e por fim o Repositório que está lá para buscar entidades persistidas para auxiliar o serviço em algo, ou simplemente para exibi-las ao usuário. Resumão correto ?

sergiotaborda wrote:O ponto é: Repositorios são mais uteis. entidades podem usar repositorios, mas não é bom poluir a interface da entidade com métodos de pesquisa especializada. Isso é função do repositorio.

Se o repositório é o cara que faz isto bem - e você já me explicou como ele faz isto =) - onde eu poderei chamá-lo para trazer estes resultados ? Se o ServiçoX precisar de dados do Repositório, ele pode e deve chamá-lo. Legal, mas e se o Serviço não precisar ? Vamos supor que eu simplemente queira exibir na tela os Pedidos finalizados do mês 11. Então eu iria fazer:

RepositorioPedido.pedidosFinalizadosDoMes(11).findAll()
Mas onde eu poderia chamá-lo, se na Action você disse-me que não seria legal entupi-la de chamadas à repositórios ?

sergiotaborda wrote:O ideal é vc ter um objeto ProductReportService ou algo assim e ter lá os métodos. internamente esses métodos pode requisitar mais do que uma informação ao repositorio e fazer liogicas de filtro, agrupamento etc que o repositorio não faz.

Maneiro. Os serviços servem para um bocado de tarefas =) Já vi gente comentando sobre Serviços estáticos. Seria isto interessante ?

sergiotaborda wrote:Não. O correto é que o serviço sim altere o estado sem utilizar o serviçoPedido.
Cada serviço sabe o que está fazendo e seu papel no grande esquema das coisas. Ele tem liberdade e capacidade para tomar a decisão de alterar o estado. Como tal ele pode alterar o estado sozinho.

sergiotaborda wrote:A palavra chave ai é "entupir". Se o action faz mais de uma chamada então ele está desenvolvendo uma logica que não se limita apenas a encaminhar os dados de um lugar ( repositorio) para outro (tela).
Não ha mal em que a action consulte directamente o repositorio se for apenas isso que ela faz.
Mas se o fizer sentir melhor, vc pode criar um façade para fazer essa chamadas pela action.
Contudo acho que ai é complicar. O principio da parcimónia vale nesse caso , eu acho.
O encapsulamento da pesquisa já esta no repositorio, encapcular isso ainda mais parece inutil

sergiotaborda wrote:Não sei o que isso significa mas:
1) se significa usar métodos estáticos, esqueça
2) se significa ter coisas tipo singleton , esqueça
3) se significa ter algum tipo de mecanismo que garante que apenas existe uma instancia do serviço, sim. isso é uma boa. Repare que os serviços não têm estado. Assim sendo um mesmo objeto pode processar qualquer numero de chamadas ao serviço.

sergiotaborda wrote:Uma outra coisa: serviços são definidos em interfaces e implementados à parte. Isso é a "marca d' água" básica de um serviço.

sergiotaborda wrote:
interface da entidade = conjunto de métodos da entidade.

é ruim ter uma entidade com dezenas de métodos que não lhe dizem directamente respeito.

hlegius wrote:

sergiotaborda wrote:Não. O correto é que o serviço sim altere o estado sem utilizar o serviçoPedido.
Cada serviço sabe o que está fazendo e seu papel no grande esquema das coisas. Ele tem liberdade e capacidade para tomar a decisão de alterar o estado. Como tal ele pode alterar o estado sozinho.

Hum. Então um Serviço só falaria com outro Serviço caso uma rotina do ServiçoA.metodoA() fosse executar uma rotina inteira do ServiçoB.metodoB() que já existe pois essa rotina "B" também é necessária viver separadamente por causa de outra necessidade do domínio, penso eu. Correto ?

sergiotaborda wrote:A palavra chave ai é "entupir". Se o action faz mais de uma chamada então ele está desenvolvendo uma logica que não se limita apenas a encaminhar os dados de um lugar ( repositorio) para outro (tela).
Não ha mal em que a action consulte directamente o repositorio se for apenas isso que ela faz.
Mas se o fizer sentir melhor, vc pode criar um façade para fazer essa chamadas pela action.
Contudo acho que ai é complicar. O principio da parcimónia vale nesse caso , eu acho.
O encapsulamento da pesquisa já esta no repositorio, encapcular isso ainda mais parece inutil

Ao que entendi, caso a Action apenas deseje exibir uma busca, sem crimes ela criar o Criteria na Action e listar os elementos.

Agora se um Repositório chamar uns dados, outro chamar outros dados contando com o primeiro criando assim uma sequencia, seria melhor encapsular isso ae numa façade para manter as coisas em paz.

hlegius wrote:
Agora se um Repositório chamar uns dados, outro chamar outros dados contando com o primeiro criando assim uma sequencia, seria melhor encapsular isso ae numa façade para manter as coisas em paz.

sergiotaborda wrote:
Sim. Mas o façade pode ele mesmo ser um repositorio. ( ele é um repositorio daquil o que vc está procurando)

sergiotaborda wrote:não se trata do métodoA ser chamado ou não. Não se trata de reaproveitamento de codigo.
Trata-se de consumir serviços. Você pode lavar o seu carro ou consumir o serviço de um lavador de carros.
Se o lavador não está disponível ou é caro demais vc mesmo faz - sabendo que a qualidade é menor.
quanto mais o serviço é especializado e/ou importante mais uso vc fará de um serviço e menos vc tentará fazer sozinho.

sergiotaborda wrote:Perai , não foi isso que eu disse.

Marcio Duran wrote: O Repositório é uma abstração, só representa a maneira de se obter as informações, é o elemento que modelamos quando necessitamos efetuar buscar por entities, outra nota é responsável por adicionar um novo item a coleção.

sergiotaborda wrote:Sim. Mas o façade pode ele mesmo ser um repositorio. ( ele é um repositorio daquil o que vc está procurando)

hlegius wrote:Então foi o que o Sergio também comentou. O próprio Façace pode ser um Repositório.