Dúvidas sobre camada acima da de persistência

Front-end
#1

Olá,

Estou estudando pelo livro “Spring in Action”, e o autor, num de seus exemplos, cria a camada de persistência com o Hibernate e, depois, no capítulo sobre Transactions, ele cria classes que acessam a camada de persistência (ele as chamou de classes Service), como mostra o código de exemplo abaixo:

// classe da persistência
public class LivroDAO {
...
    public void addLivro(Livro livro){
        currentSession().save(livro);
    }
...
}

//classe Service
public class LivroService {
...
    public void addLivro(Livro livro){
        livroDao.addLivro(livro);
    }
...
}

Quando ele falou de transactions programáticas (por código Java e não XML), os códigos da transaction foram adicionados nos métodos da classe LivroService.

Minhas dúvidas são:
-> Por que essas classes que acessam a camada de persistência devem ser implementadas? Elas devem ser implementadas somente quando eu for usar transactions?
-> Como eu usarei as transactions, eu crio um pacote separado para as classes Service (um pacote “service”, por exemplo)?
-> Cada classe DAO terá uma classe Service correspondente?

Agradeço.

#2

as vezes queremos controlar a transação pois nem sempre queremos realizar o autocomit, vai depender de regra de negocio do sistema
pensem em um processamento batch, isso vai depender das condições e nem sempre será automatico.
usar ou não o service depende do que voce quer fazer pra isolar o DAO das classes de controle, quase sempre é overhead de codigo inútil pra manter purismo de arquiteto novato.
tenho por mim que nada impede que o EJB seja injetado direto no controler, use servce só quando isso for justificavel, tempo é dinheiro e o cliente nao paga por estes purismos tolos.

#3

acho que essa relação DAO->Service não deve ser 1x1, essa camada Service tem que conter regras de negócio (Nem vou discutir a existência da camada… Sou mais uma abordagem DDD… Mas dependendo do nível de padronização que você precisa não tem como fugir rsrs). Por exemplo:

LivroDAO, AutorDAO, ColecaoDAO…

Serão usados por serviços:

BibliotecaService, EmprestimoService, DevolucaoService…

Eu penso que assim fica menos anêmico o modelo, já que você optou por ter essa camada de Services.

#4

se nao pretende usar do conceito de serviço evite isso aí pois só vai dar trabalho.

#5

Percebo que vai partir mais das minhas escolhas mesmo, achava que era algo mais rígido.

Agradeço as respostas!

#6