JPA + Resfful Service

Olá galera.

Vocês veem algum bom motivo para não mapear em uma única classe annotations jpa e rest.

@Entity
@Path("/xyz")
Objeto {

}

No contexto da minha app isso não teria problema algum. Alguém já teve problemas com isso?

Nossa… você iria persistir um serviço? Boa sorte!

Velho… cade a Modularização? Camadas?
Reaproveitamento é Luxo?! entre outras coisitas mais!!!

Assim como nosso amigo disse acima: Persistir um Serviço? Good Luck!!!

Não né. A classe tem responsabilidades, o fato de você colocar annotations na classe você está adicionando metainfos na classe que será utilizada por alguém. Se você incluir @Entity na classe não significa que a classe não possa ter métodos na classe além de setters/getters. Certo?

Nada impediria de disponibilizar um método na minha classe que fornece um serviço para alguém.

Então vocês criam objetos anêmicos. É isso? Sua classe que tem @Entity só tem setter/getter e aí provavelmente vocês criam um ObjetoManager. Cade o especialista da informação?

Eu vejo que modularizar é importante mas quando há necessidade. Agora querer modularizar por luxo ou preciosismo é desnecessário, gera complexidade, etc.

Ô meu Deus… distorcer a informação é isso aí.

Não é questão de criar objetos anêmicos. A questão é que você está misturando duas coisas que violam o princípio mais básico da OO : a coesão. Misturando tudo isso, você corre sérios riscos (do seu framework JAX-RS não suportar essas propriedades, de você querer trafegar esse objeto pra algum lugar que não tenha suporte pra JAX-RS, etc.)

Não defenda isso como objeto não-anêmico, porque isso é outra coisa.

Fazendo uma analogia, é mesma coisa que ter um objeto assim:
@Entity
@XmlRootElement
Objeto{
//…
}

Isso significa que você vai colocar uma tabela, coluna, etc no xml ou vice-versa. Sinceramente até o momento não há argumentos suficientes.

[quote=tcf]Fazendo uma analogia, é mesma coisa que ter um objeto assim:
@Entity
@XmlRootElement
Objeto{
//…
}

Isso significa que você vai colocar uma tabela, coluna, etc no xml ou vice-versa. Sinceramente até o momento não há argumentos suficientes.[/quote]

Não, isso quer dizer que você está permitindo que sua entidade seja serializável como XML. Sem problemas com isso.

Problema há quando você quiser persistir uma coisa que obviamente não é persistível. Você já pensou o que vai fazer com isso quando você ler de volta do banco? A cada vez que fizer uma releitura do banco, você vai ter um serviço novo? E quando você fizer uma requisição pra esse serviço, o contêiner JAX-RS vai ter que criar suas entidades pra você ter que persistir no banco? Já passou pela sua cabeça que um contêiner JAX-RS pode muito bem fazer instrumentação pra coisas como segurança, por exemplo? E que essa instrumentação pode adicionar campos no seu serviço que você não vai querer /poder persistir?

De novo… boa sorte!!!

Ok. Agora estou convencido. Bons argumentos.

Obrigado =)

Convenceu +ou- porque se for programar assumindo que tem N fatores transversais ao que você está fazendo você acaba fazendo nada.

Nada impediria ter uma instância da classe criada pelo web-container e uma outra instância criada pelo hibernate e outra criada por mim.

[quote=tcf]Convenceu +ou- porque se for programar assumindo que tem N fatores transversais ao que você está fazendo você acaba fazendo nada.

Nada impediria ter uma instância da classe criada pelo web-container e uma outra instância criada pelo hibernate e outra criada por mim.[/quote]

Está percebendo o tanto de complexidade você teria que adicionar pra contornar um problema que seria facilmente resolvido se você simplesmente separasse as duas coisas?

Então na verdade estamos expondo e especulando não sabemos o que aconteceria e se aconteceria.

talvez a gente tivesse a fazer o IoC da pergunta. Você já pensou como simplificaria se encapsulasse o serviço no objeto que é pertinente.

Talvez se esse objeto começasse a ficar “gordo” e fazendo coisas demais aí poderíamos fazer a separação natural das coisas e aí sim criar objetos com responsabilidades mais particulares e “granularizar” as coisas.

Cara, você já tomou a sua decisão e está querendo simplesmente que alguém te diga que sua decisão está certa.

Boa sorte.

Um exemplo. Nada impediria de ter um método assim no meu objeto:

@Entity
class Objeto{
//…
public static Objeto of (id){
return em.find(Objeto.class, id);
}
//…
}

[quote=tcf]Um exemplo. Nada impediria de ter um método assim no meu objeto:

@Entity
class Objeto{
//…
public static Objeto of (id){
return em.find(Objeto.class, id);
}
//…
}[/quote]

Já disse. Você só está procurando alguém pra falar que sua idéia está correta, pra você ir fundo. Você não vai encontrar ninguém assim aqui.

Boa sorte.

… “Talvez se esse objeto começasse a ficar “gordo” e fazendo coisas demais aí poderíamos fazer a separação natural das coisas e aí sim criar objetos com responsabilidades mais particulares e “granularizar” as coisas.”

Você mesmo já deu o seu argumento por que não usar tudo dentro de um Serviço, que no meu ponto de vista, deve ser Simples e sucinto!

Bem apenas para constar encontrei um artigo no site da oracle que fala exatamente disso. Ele disse que é perfeitamente aceitável, repito, perfeitamente aceitável…

Agora que sabem que há um artigo de alguém falando que pode vocês vão seguir as cegas.

abs

[quote=tcf]Bem apenas para constar encontrei um artigo no site da oracle que fala exatamente disso. Ele disse que é perfeitamente aceitável, repito, perfeitamente aceitável…

Agora que sabem que há um artigo de alguém falando que pode vocês vão seguir as cegas.

abs[/quote]

[ironia mode=on]
Sim, claro. Afinal, o pessoal da Oracle é perfeitamente confiável, sempre faz produtos bons, não erra nunca…
[/ironia]

Já disse, se você quer alguém pra ficar passando a mão na sua cabeça e concordando com tudo o que você diz, aqui não é o lugar onde você vai encontrar.

P.S: Artigo da Oracle, é? Se importaria em passar o link?