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?
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?