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?