Spring - Qual a vantagem da camada Service

[Dionatan Hovoruski]

No meu sistema ao qual integrei o spring, fiz as adaptações para deixa-lo conforme um modelo na internet. Ele é composto pela seguinte arquitetura:

- Model
- Controller
- DAO
- Util
- Service
- Views

Porém até o momento não entendi as vantagens da camada service, visto que ele apena instancia o DAO.

[Tiago Augusto Nogueira Coelho]

Os seus services são os serviços do seu sistema. As suas regras ficariam dentro dele.

Por exemploi, vc pode ter um serviço de Enviar email, gerar boleto manter usuário etc. Os serviços usam os DAO para acessar os dados.

[Renieri]

Se eu estiver errado me corrijam. Na camada service vc coloca suas regras de negócio retirando das views e controller estas regras

--
Você recebeu esta mensagem por que é membro do Javasf
http://groups.google.com/group/javasf
 
Conheça também o Java Brazil: http://groups.google.com/group/thejavabrazil

[Walter Mourão]

A grande vantagem (do ponto de vista do desenvolvedor) dos serviços é concentrar as regras de negócio para facilitar a manutenção. Em sistemas pequenos não faz muito sentido mesmo não.

Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br

2012/1/3 Renieri <rayron....@gmail.com>

[Fernando Oliveira]

Também tinha essa dúvida sobre o que é essa camada service. 

No caso, é a camada de regra de negócios?! 

Em alguns projetos vi que chamam de BO, seria a mesma coisa com nomenclaturas diferentes?!

atc,


Fernando Oliveira
Desenvolvedor Java / PHP

http://about.me/nandooliveira

(82) 8841-7959 / 9927-4021     

[Renieri]

Isso, ja vi projetos que chamam de services, BO, businness, etc

[Walter Mourão]

Sim, é a camada das regras de negócio e seus elementos também são chamados de Business Objects, serviços... mas depende do gosto do freguês :-)

Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br

2012/1/3 Fernando Oliveira <nandooli...@gmail.com>

[Rafael Roque]

Eu concordo com essa visão.

No meu caso,como meus sistemas são acesso "puro" ao BD,preferi matar a
camada Service e injetar o DAO diretamente no controller via
@Component.

On Jan 3, 9:50 am, Tiago Augusto Nogueira Coelho

[Bruno Maomeh]

as regras de negócio não deveria estar dentro do teu modelo? por exemplo.. se você tem uma classe pessoa, e essa pessoa precisa andar.. você criaria uma service para ela andar?

class pessoaService {

   void anda(Pessoa pessoa) {

       pessoa.setPernaDireita("40 cm");

       pessoa.setPernaEsquerda("40 cm");

       ...

   }

}

acho isso meio errado! :)

--
Você recebeu esta mensagem por que é membro do  Javasf
http://groups.google.com/group/javasf

Conheça também o Java Brazil: http://groups.google.com/group/thejavabrazil

--
Bruno Maomeh
   http://brunomaomeh.wordpress.com

[Walter Mourão]

Esse exemplo é muito simplista... quando a pessoa anda ele pode trombar nas paredes ou em outras pessoas. Algumas pessoas (eu, por exemplo) prefirem que um serviço ajude a controlar a interação entre os objetos.

Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br

2012/1/3 Bruno Maomeh <bruno...@gmail.com>

[Rafael Ponte]

Oi Dionatan,

Existe várias vantagens em se utilizar Spring, se você pesquisar você poderá encontrar blog posts e artigos comentando sobre estas vantagens. Mas apenas para citar duas, 1) que considero importante e comum a maioria das apps é o controle transacional, que é de qualidade e muito simples e 2) incita o desenvolvimento voltado a interfaces, o que facilita a escrita de testes automatizados;

No mais, normalmente (não é regra) me utilizo dessa abordagem com Spring, https://github.com/rponte/jsf-loja-project .

2012/1/3 Dionatan Hovoruski <dionat...@gmail.com>

--
Você recebeu esta mensagem por que é membro do Javasf
http://groups.google.com/group/javasf
 
Conheça também o Java Brazil: http://groups.google.com/group/thejavabrazil

--
Rafael Ponte
http://www.triadworks.com.br

[Rafael Ponte]

Walter,

Assim como o Bruno comentou, eu também coloco minhas regras de negócio no meu modelo. Meus services/façades (ou seja, app layer) eu utilizo para orquestrar meus objetos de modelo e a interação entre eles e demais componentes.

2012/1/3 Walter Mourão <walter...@gmail.com>

--
Rafael Ponte
http://www.triadworks.com.br

[Dionatan Hovoruski]

Bom pelo qu eu entendi então, seria mais ou menos isso:

View - As "telinhas"
Controller - A "ponte" entre a visão e a camada de serviço
Service - Regras de negócio
DAO - Persistencia e transações com o banco em geral

Desde já agradeço as respostas e me corrijam se eu estiver errado.

[Walter Mourão]

Oi Rafael,
pois é, eu entendo e respeito a abordagem, só não gosto muito (ou não me acostumei) e prefiro a abordagem de modelo anêmico, provavelmente reflexo de alguns traumas do tempo do Delphi... ;-)

Sds,

Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br

2012/1/3 Rafael Ponte <rpo...@gmail.com>

[Bruno Nandolpho]

Galera, independente de se usar @Service, é possível separar uma
classe que tenha as regras de negócio nela e ela ser anotada com
@Component. Ou até mesmo @Repository e vai funcionar. O importante é
saber as diferenças e vantagens de se utilizar cada anotação spring
com a necessidade.


@Service
->Essa anotacao, assim como @Repository e @Controller, permitem que
possa ser utilizado orientacao a aspectos, criando pontos para
interceptar os metodos da classe. Ou seja, em um primeiro nível, se
for uma camada de servicos ou negócios, ou @Component ou @Service
deveriam ser utilizados. E o @Service tem essa vantagem a mais q o
@component


@Repository
->Repository permite que o spring traduza várias excecoes de
persistencia para excecoes conhecidas. Não eh preciso esperar excecao
JPA ou JDO ou Hibernate. Ele captura essas exceptions especificas e
encapsula em excecoes spring automaiticamente, deixando transparente
para a aplicacao qual tipo de persistencia esta sendo utilizado. Faz
todo sentido colocar em uma classe que funcione com data acess objet,
e a documentacao spring inclusive fala disso.

On 3 jan, 15:31, Walter Mourão <walter.mou...@gmail.com> wrote:
> Oi Rafael,
> pois é, eu entendo e respeito a abordagem, só não gosto muito (ou não me
> acostumei) e prefiro a abordagem de modelo anêmico, provavelmente reflexo
> de alguns traumas do tempo do Delphi... ;-)
>
> Sds,
>

> Walter Mourãohttp://waltermourao.com.brhttp://arcadian.com.brhttp://oriens.com.br

>
> 2012/1/3 Rafael Ponte <rpo...@gmail.com>
>
> > Walter,
>
> > Assim como o Bruno comentou, eu também coloco minhas regras de negócio no
> > meu modelo. Meus services/façades (ou seja, app layer) eu utilizo para
> > orquestrar meus objetos de modelo e a interação entre eles e demais
> > componentes.
>

> > 2012/1/3 Walter Mourão <walter.mou...@gmail.com>

>
> >> Esse exemplo é muito simplista... quando a pessoa anda ele pode trombar
> >> nas paredes ou em outras pessoas. Algumas pessoas (eu, por exemplo)
> >> prefirem que um serviço ajude a controlar a interação entre os objetos.
>
> >> Walter Mourão
> >>http://waltermourao.com.br
> >>http://arcadian.com.br
> >>http://oriens.com.br
>

> >> 2012/1/3 Bruno Maomeh <brunomao...@gmail.com>

>
> >>> as regras de negócio não deveria estar dentro do teu modelo? por
> >>> exemplo.. se você tem uma classe pessoa, e essa pessoa precisa andar.. você
> >>> criaria uma service para ela andar?
>
> >>> class pessoaService {
> >>>    void anda(Pessoa pessoa) {
> >>>        pessoa.setPernaDireita("40 cm");
> >>>        pessoa.setPernaEsquerda("40 cm");
> >>>        ...
> >>>    }
> >>> }
>
> >>> acho isso meio errado! :)
>