Nem sempre, ela já existe no banco de dados. Você pode ter uma entidade para fins de consulta apenas.
Digamos que a sua aplicação utilize de dados comprados por uma terceira empresa. Esses dados são carregados numa tabela via loader. Os desenvolvedores PL/SQL fizeram uma série de lógica para tratar esses dados e entregar uma view/tabela/view materializada para você. O usuário que a sua aplicação vai usar para se conectar no banco de dados não pode fazer insert, update ou delete nessa tabela, pois ele só possui o grant de select.
Se isso, que você me disse, define uma entidade, a saída lógica seria não ter essa entidade, certo? Prefere fazer os selects e relacionamentos na mão ou usar o Hibernate e ter uma classe que representa essa view/tabela/view materializada?
[quote=pfk66]
No caso das transações, quem executa é responsável por lidar com os casos onde eventualmente a transação falha. Isso geralmente é responsabilidade da camada de aplicação? Não vejo necessidade de projetar minhas entidades para estarem “cientes” disso.[/quote]
Isso é DAO, que é aonde ele estava usando a herança.
[quote=pfk66]
Lembrando que, mesmo quando a transação falha em alguns casos o DBA pode querer saber as entidades que o usuário não autenticado tentou salvar.[/quote]
Quando eu falo usuário, me refiro ao usuário de conexão no banco de dados, não o usuário da aplicação.
@andersonscherrer
Sim, a diferença não é grande. Basta apenas repassar e pronto, já está adotando um padrão de projeto.
Sobre questão do JAR X WebService. Na minha opinião, não faz muita diferença prática.
É uma decisão que vem acompanhada de vários prós e contras. Pode fazer sentido você apenas compartilhar os daos e regras de negócio.
Eu, particularmente, prefiro trabalhar com WebServices. Pois é mais prático para ter aplicações web e mobile.
//aqui eu uso o VRaptor ele deserializa pra mim o JSON
public void gravar(Pessoa pessoa){
// validar pessoa
// chamar o DAO ou o Service para gravar
dao.gravar(pessoa);
}
Ele sugeriu receber um DTO. Devido a alguns problemas que eu citei pra ele por exemplo controlar os dados que podem ser deserializados pelo JSON
criei algo do tipo
class PersistentPessoa{
public final String nome;
public final List<Endereco> enderecos;
public PersistentPessoa(String nome; List<Endereco> enderecos){
this.nome = nome;
this.enderecos = enderecos;
}
Assim eu receberia esse DTO no Controller.
Aqui tenho dúvidas, porque o Endereco também precisa ser um DTO, e outra, como foi sugerido o DTO deveria servir a apenas UMA Action do controller, então preciso ter um “TransientPessoa” que vai ser pra Atualizar pessoa?
Eu já li sobre DDD, mas na prática, se não tiver ajuda de quem já mexeu com isso Comercialmente é difícil aplicar.
Eu estou a vários dias pesquisando mas não consegui transformar a Teoria em prática, e pensei que alguém pudesse passar a sua experiência aqui, como acontece na maioria das vezes, inclusive nesse tópico.
Estou em um projeto novo e tenho a oportunidade de melhorar meu código, quero deixar o mais reutilizável, e limpo. E E sei que o povo aqui ajuda muito, além disso quero deixar o post aqui pra quem precise possa vir e consultar.
Talvez eu coloque esse código no github para quem queira usá-lo mas no momento não tenho tempo pra documentar.
[quote=FernandoFranzini]DDD é não dificil de aplicar…é uma paradigma novo a aprender…toda essa discussão ai de vcs…ja esta tudo resolvido por la…
Vc vai gastar mais tempo esperando respostas dos outros, discutindo do que aprendendo DDD…
Falo isso por experiência própria…
[/quote]
Pois é, eu consegui dar uma boa melhorada no projeto pesquisando sobre arquiteturas e DDD, com certeza um ou outro vai ter opinião divergente. Mas fica aí o post para quem queira mostrar alguma coisa nova é valido.
Eu já li sobre DDD, mas na prática, se não tiver ajuda de quem já mexeu com isso Comercialmente é difícil aplicar.
Eu estou a vários dias pesquisando mas não consegui transformar a Teoria em prática, e pensei que alguém pudesse passar a sua experiência aqui, como acontece na maioria das vezes, inclusive nesse tópico.
Estou em um projeto novo e tenho a oportunidade de melhorar meu código, quero deixar o mais reutilizável, e limpo. E E sei que o povo aqui ajuda muito, além disso quero deixar o post aqui pra quem precise possa vir e consultar.
Talvez eu coloque esse código no github para quem queira usá-lo mas no momento não tenho tempo pra documentar.[/quote]
DDD à risca é muito complexo, não vale o investimento dessa complexidade técnica enquanto o cliente quer retorno para o Negócio. Parece difícil para muitos fazer o simples. Só o padrão Repository reconheço que é interessante.
[quote]
DDD à risca é muito complexo, não vale o investimento dessa complexidade técnica enquanto o cliente quer retorno para o Negócio. Parece difícil para muitos fazer o simples. Só o padrão Repository reconheço que é interessante.[/quote]
Pois é, é muito conceito teórico, do tipo: Não use herança, Não use o tal do Service, Não use modelo anêmico, SEMPRE use interface, etc… Que são conceitos de certificação, ou de desenvolvimento de frameworks, que não se aplica 100% em prática. Inclusive não encontrei NENHUM exemplo prático de DDD que compreendesse as necessidade de um CRUD que envolvesse duas Tabelas com @ManyToOne. Estou me virando mas pelos que vejo na teoria achei que alguém pudesse mostrar em prática alguma coisa que ajudasse.
[quote=andersonscherrer][quote]
DDD à risca é muito complexo, não vale o investimento dessa complexidade técnica enquanto o cliente quer retorno para o Negócio. Parece difícil para muitos fazer o simples. Só o padrão Repository reconheço que é interessante.[/quote]
Pois é, é muito conceito teórico, do tipo: Não use herança, Não use o tal do Service, Não use modelo anêmico, SEMPRE use interface, etc… Que são conceitos de certificação, ou de desenvolvimento de frameworks, que não se aplica 100% em prática. Inclusive não encontrei NENHUM exemplo prático de DDD que compreendesse as necessidade de um CRUD que envolvesse duas Tabelas com @ManyToOne. Estou me virando mas pelos que vejo na teoria achei que alguém pudesse mostrar em prática alguma coisa que ajudasse.[/quote]
Pois é, essa coisa de “interface para tudo” muitas vezes fica só num processo burocrático para atender a uma doutrina de TI, onde na prática pode nunca existir mais de uma implementação para determinado caso. Se existir a real necessidade, tudo bem. Mas essa coisa de ficar supondo “se talvez no futuro acontecer” não é uma prática ágil, o foco deve ser no horizonte real do cliente.
Não entendi que dúvida você precisa tirar inicialmente. Sobre “@ManyToOne”, isso é relacionado ao ORM Hibernate, onde deverá pesquisar sobre o mesmo, independente de outras coisas.
[quote=andersonscherrer][quote]
DDD à risca é muito complexo, não vale o investimento dessa complexidade técnica enquanto o cliente quer retorno para o Negócio. Parece difícil para muitos fazer o simples. Só o padrão Repository reconheço que é interessante.[/quote]
Pois é, é muito conceito teórico, do tipo: Não use herança, Não use o tal do Service, Não use modelo anêmico, SEMPRE use interface, etc… Que são conceitos de certificação, ou de desenvolvimento de frameworks, que não se aplica 100% em prática. Inclusive não encontrei NENHUM exemplo prático de DDD que compreendesse as necessidade de um CRUD que envolvesse duas Tabelas com @ManyToOne. Estou me virando mas pelos que vejo na teoria achei que alguém pudesse mostrar em prática alguma coisa que ajudasse.[/quote]
A coisa mais importante que DDD diz é: Não compartilhe o banco de dados entre aplicações; Não use o banco de dados pra armazenar outra coisa senão objetos.
DDD não vai oferecer retorno se você vê o sistema de banco de dados como algo separado e que interage com o sistema OO.
DDD é uma estratégia…é um caminho…uma diretriz…
DDD não te força a fazer nada…vc tem que decidir com base no seu projeto…
Isso q vc estão falando não é DDD do Erik Vans…
DDD é uma estrategia de arquitetura para ser simples, rápido e fácil…o ser OO…
Infelizmente não tem como discutir DDD dentro de um contexto no forum…seria algo muito demorado…
[quote=FernandoFranzini]Me desculpem, mas vou ter q dizer…
DDD é uma estratégia…é um caminho…uma diretriz…
DDD não te força a fazer nada…vc tem que decidir com base no seu projeto…
Isso q vc estão falando não é DDD do Erik Vans…
DDD é uma estrategia de arquitetura para ser simples, rápido e fácil…o ser OO…
Infelizmente não tem como discutir DDD dentro de um contexto no forum…seria algo muito demorado…
Mas fica a dica ai…
T+[/quote]
Nao acho isso simples, por mais que nao force algo…
Foco no negócio, simplicidade, manutenibilidade, etc, são coisas óbvias para um time entrosado com nível de experiência média plena. Adotar algo para “ser OO…” é pensar mais em TI do que atender o Negocio. Prefiro não adotar soluções para problemas que não existem. Quem geralmente precisa de diretrizes são fábricas de softwares, lugares com alta rotatividade ou equipe pouco experiente, ai sim concordo que o DDD deve fazer sentido.
[quote=pfk66][quote=javaflex]
Nao acho isso simples, por mais que nao force algo…
Foco no negócio, simplicidade, manutenibilidade, etc, são coisas óbvias para um time entrosado com nível de experiência média plena. Adotar algo para “ser OO…” é pensar mais em TI do que atender o Negocio. Prefiro não adotar soluções para problemas que não existem. Quem geralmente precisa de diretrizes são fábricas de softwares, lugares com alta rotatividade ou equipe pouco experiente, ai sim concordo que o DDD deve fazer sentido.
[/quote]
Se você tem uma aplicação simples não precisa de DDD, usa Smart UI.[/quote]
Me referi sobre “simples” em relação a arquitetura e não a aplicação a nível de processos de Negócio. Não é porque a aplicação é complexa que precisamos de DDD, nem se a aplicação for simples tem que chegar ao extremo oposto de seguir “Smart UI”, como se fosse 8 ou 80. Mas enfim, cada equipe escolhe o que precisa ou não para atender as demandas no dia a dia.
[quote=AbelBueno]Particularmente, acho que sua dúvida tem muito mais a ver com arquitetura do que com DDD.
Eu recomendaria muito ir para a opção de compartilhar essa api via web service ao invés de jar.
Alguns dos problemas que vejo com jars são:
tem que fazer deploy de todos seus clientes quando há uma mudança no core
tem que “carregar” configurações do core para seu cliente (endereço do db, urls)
aumenta risco de conflito de versões entre aplicativos (quero usar lib A 2.0 no client web, mas meu core só funciona com A 1.0)
Não sei quanto desses problemas seriam reais no seu caso, mas eu prefiro nunca compartilhar jars.
[/quote]
Minha dúvida na verdade era Melhorar o código ou a relação entre as camadas e actions. Por ex. agora estou sem a camada Service, recebo DTO no controller, chamo o DAO/Repository e este por sua vez cria as Entidades através dos DTOs e persiste ou atualiza etc, antes eu tinha o Service no meio do caminho, e também não recebia DTO no controller, recebia direto a Entity.
Sobre compartilhar .jar até agora está indo bem, é meio que “viajem” da minha parte, mas já não estou mais precisando copiar código em cada projeto novo.
E trabalhando direitinho com o maven, estou conseguindo me virar, por enquanto não teve problema de versão de biblioteca.
