[quote=Bruno Laturner][quote=qmx]Porque ainda tem gente que acha que SGBD’s são uma tecnologia não-madura, que nunca vai emplacar e acreditam no coelhinho da páscoa.
Sinceramente, acredito mais na possibilidade de ORM ser uma gambiarra do que SQL (Eu amo ORM, diga-se de passagem).
Não dá pra simplesmente jogar fora anos de pesquisa e maturação. Algumas coisas vc usa (Query’s malucas pra tirar o relatório que o chefe pediu pra ontem), outras vc coloca na prateleira e diz o quanto já te foi útil (Struts 1.x)
:mrgreen:
Desculpem o tom irônico, aprendi essa lição da pior forma possível… Não desprezar o que o mercado usa… Não desprezar o que o mercado usa…
e principalmente, não cuspa em uma tecnologia, pode ser que ela encha sua orelha de grana amanhã.[/quote]
Não tenho nada contra SGBDs, aliás a teoria dos conjuntos e a relacional são umas das mais úteis no campo da matemática aplicada. Tem lugar garantido.
Só tenho muita coisa contra SQL(e DDL):
[list][] é a linguagem padronizada com mais implementações não-padrão que existe;
[]qualquer coisa fora de CRUD de uma tabela só é um horror para montar;
[*] e que ela é uma linguagem humanizada demais, sendo que seus clientes principais são programas de computador, e dá-lhe horas gastas traduzindo um modelo p/ outro.[/list]
[size=7](Off: este software jforum tb é outra porc…)[/size][/quote]
Tudo bem se você acha SQL uma porcaria, agora então quais seriam as alternativas para se fazer uma query onde eu precise juntar dados de duas ou mais tabelas??
[quote=pcalcado]Como disseram antes, não se pode afirmar que seu modelo é anêmico porque você não postou sequer a classe toda.
Mas, anêmica ou não, me parece que sua classe tem ums problemas de modelagem. 23 atributos?[/quote]
Philip eh que o E-commerce foi feito com um banco de dados legado, onde já funcionava um sistema assim com todos estes controles no PedidoDeVenda, somente segui o que a empresa ja tinha.
Quanto a classe toda, a minha duvida toda eh justamente essa, visto que a classe isso ai + os getters porque eu nao preciso de um set, pois ela imutavel tudo eh setado no construtor, entao ela possue um construtor gigante. Queria saber se isso caracteriza um modelo anêmico eh se ha outras alternativas?
[quote=danielbussade]
Quanto a classe toda, a minha duvida toda eh justamente essa, visto que a classe isso ai + os getters porque eu nao preciso de um set, pois ela imutavel tudo eh setado no construtor, entao ela possue um construtor gigante. Queria saber se isso caracteriza um modelo anêmico eh se ha outras alternativas?
Att [/quote]
Isso não tem muito a ver com modelo anêmico mas tem a ver com modelagem ruim. Não é porque sua tabela etá modelada de uma maneira estranha que seus objetos precisam estar, você pode ter vários objetos sendo populados por uma tabela. Aliás, criar modelos 1-para-1 entre classes e tabelas com bases de dados legads quase sempre é um péssimo negócio.
[quote=pcalcado][quote=danielbussade]
Quanto a classe toda, a minha duvida toda eh justamente essa, visto que a classe isso ai + os getters porque eu nao preciso de um set, pois ela imutavel tudo eh setado no construtor, entao ela possue um construtor gigante. Queria saber se isso caracteriza um modelo anêmico eh se ha outras alternativas?
Att [/quote]
Isso não tem muito a ver com modelo anêmico mas tem a ver com modelagem ruim. Não é porque sua tabela etá modelada de uma maneira estranha que seus objetos precisam estar, você pode ter vários objetos sendo populados por uma tabela. Aliás, criar modelos 1-para-1 entre classes e tabelas com bases de dados legads quase sempre é um péssimo negócio.[/quote]
Então philip mas nao vejo quase nada par ser retirado da classse e colocada em outra, mas mesmo se colocasse alguns atributos em outro objeto qual vantagem eu teria, visto que os mesmos tbm nao possuiriam regras de negócio?
O que estou tentando entender eh se uma classe onde quase todos seus atributos são definidos no construtor eh um modelo anêmico , ou o modelo anêmico eh somente quando se separa atributos de metodos(VO e BO)?
Será que não teriam? É difícil falar sem conhecer o domínio mas eu acho muito difícil.
Creio que você não consegue pensar nas regras de negócio sobre estes objetos porque estas regras de negócio estão espalhadas por outros lugares. Dê uma olhada em quem usa estes atributos e pense se quem os maniula deveria estar fazendo isso ou se esta deveria ser uma reponsabilidade do objeto.
Fora uns relacionamentos estranhos. Pedido tem um endereço e um cliente. Será que na verdade não seria o Cliente que tem um endereço?
Outro ponto interessante é o ‘idVendedor’. Objetos não possuem o ID de outros objetos, eles possuem relação com estes. Me parece que você simplesmente pgou o conteúdo do campi na tabela (que é uma chave estrangeira pelo que parece) e colocou no seu objeto. Para ter um domínio mais coerente você deveria ter uma relação entre Pedido e Vendedor, e não seu ID.
Além disso, o que é o total bruto? Será que ele é uma tributo mesmo ou será que é um valor derivado?
Nem um nem outro. Como já dissemos aqui algumas vezes não dá para dizer se sua classe é anêmica ou não. Uma classe anêmica não vai conter regras de negócio dentro dela, vai ser apenas um agrupamento de dados. Onde ficam as regras de negócio do pedido no seu sistema?
Isso realmente foi um erro, o correto seria criar uma classe Vendedor e Pedido ter um Vendedor.
Philip este endereço do Pedido eh o endereço de entrega que muitas vezes pode ser diferente do endereço do cliente que está fazendo o pedido, e pode mudar em cada pedido, por isso coloquei ele no pedido.
O total bruto eh o total do pedido + o juros que será aplicado de acordo com a condição de pagamento que escolher e do grupo do produto a ser comprado, cada grupo de produto junto com uma condição de uma certa quantia de juros aplicada.
Pois é, a falta de coesão na classe não te deixa ver isso. Veja só, você tem entregueAoCliente, entregaDomicilio, valorFrete, endereco e certamente outros atributos nesta classe que estão relacionados não ao pedido em si mas sim com sua entrega (e a entrega está relacionada ao produto). Será que esta modelagem não deixou escapar um objeto que modela a entrega?
Se você tem todos estes dados guardados porque você precisa guardar o resultado da comutação e não apenas calcular isso quando precisar? Não é porque algo é um atributo de um objeto que ele precisa ser implementado como um atributo.
Não dá para entender muito do seu sistema baseado nele (diagramas de classe -ou qualquer outro- não são exatamente a melhor maneira de se passar uma idéia). Como falei, sem saber o que você está fazendo é bem difícil dar palpite.
Pois é Philip agora realmente eu começo a enxergar os benefícios de se criar outras classes e nao ter uma classe faz tudo, acabei de ler um artigo no seu blog sobre ojetos Fantoche e percebi que muitas classes no meu sistema se comportam assim.
A minha dificuldade de migrar para uma Orientação a Objeto eh que eu sempre penso no SGDB, porque venho de um programação procedural.
Mas obrigado pelas dicas, e parabéns pelos artigos do blog.
Esse livro do Eric Evans, poderia me ajudar a migrar para um pensamento Orientado a Objeto se não teria alguma indicação de livro que possa me passar.
[quote=danielbussade]
Esse livro do Eric Evans, poderia me ajudar a migrar para um pensamento Orientado a Objeto se não teria alguma indicação de livro que possa me passar.
Obrigado ![/quote]
Domain-driven design e OO sao coisas bem diferentes. Se eu fosse vc nao me preocuparia com DDD num primeiro momento.
[quote=Emerson Macedo]Para migrar para um pensamento OO, Page Jones é bem legal.
[/quote]
Valeu pela indicação, estou dando uma olhada nele. Eu nunca comprei livro internacional, o inglês deste livro eh bem puxado ou eh tranquilo de entender?
Ok philip mas agora veio uma questao na cabeça; E seu precisar persistir este dado no banco, já que uso o Hibernate pra isso, como vou persistir este atributo visto que ele nao faz parte do objeto?
Não entendi, se ele é derivado e se os que o originam são persistidos por que você o precisaria persistir? Talvez não tenha ficado claro mas o que eu sugrei inclui uma mudança também no modelo de dados. Se isto não é possível então é outra história.
Como ponto relevante, se fosse o caso você poderia fazer o Hibernate utilizar métodos get/set (ou talvez métodos anotados, não conheço Hibernate Annotations) ao invés de atributos.
Desculpe eu expliquei mal, é que esse sistema e dependente de outro desktop que eh oque fatura os pedidos e usa este campo para recuperar o valor bruto, e nao tenho acesso a esse sistema entao nao posso mudá-lo por isso preciso persitir o campo tbm.
Agora voltando a questão do modelo anêmico, em uma classe simples Philip como essa:
public class User {
private Integer id;
private String login;
private String senha;
private Date dataCadastro;
}
Nesta classe onde nao tenho regra de negocio, eh um simples CRUD, acaba se tornando anêmica, porque o que acontece eh que recupero os valores que o usuario digitou com input.getParameter(“qualquerCoisa”), vindo de HttpRequest e passo todos os valores no construtor.
Quase todas as classes são assim, ou seja a minha dúvida eh se uma classe eh um simples cadastro ou seja nao tem regra de negocio envolvida acaba se tornando um agrupamento de dados, isso faz dela uma classe anêmica??
[quote=danielbussade] Desculpe eu expliquei mal, é que esse sistema e dependente de outro desktop que eh oque fatura os pedidos e usa este campo para recuperar o valor bruto, e nao tenho acesso a esse sistema entao nao posso mudá-lo por isso preciso persitir o campo tbm.
Agora voltando a questão do modelo anêmico, em uma classe simples Philip como essa:
public class User {
private Integer id;
private String login;
private String senha;
private Date dataCadastro;
}
Nesta classe onde nao tenho regra de negocio, eh um simples CRUD, acaba se tornando anêmica, porque o que acontece eh que recupero os valores que o usuario digitou com input.getParameter(“qualquerCoisa”), vindo de HttpRequest e passo todos os valores no construtor.
Quase todas as classes são assim, ou seja a minha dúvida eh se uma classe eh um simples cadastro ou seja nao tem regra de negocio envolvida acaba se tornando um agrupamento de dados, isso faz dela uma classe anêmica??
[/quote]
Mais ou menos.
Seu usuário pode alterar a senha ? Sendo assim, vc poderia colocar um método do tipo:
boolean changePassword(oldPass, new);
Seu sistema tem alguma regra forte para o password ?
Seu usuário tem permissão de acesso somente a determinadas funcionalidades ?
Vc pode adicionar esses comportamentos na classe User também.
Se vc for enxergar somente o CRUD, a classe deve ser simples, mas qdo vc começa a visualizar o relacionamento dessa entidade com o resto do sistema, você começa a evoluir o seu modelo.
Interessante as dicas. O que eu tava falando e que acho uma programação “feia” tipo tira da tela, passa tudo no construtor e da um em.persist(objeto) pro banco, fica uma coisa sem lógica nenhuma.
Mas nao tinha pensando no que você falou quando começa a interagir com o resto do sistema eh que a classe vai ganhando vida;
O maior problema disso tudo eh o seguinte, na maioria das vezes eu utilizo frameworks que fazem controle de acesso definidos por grupo, validação dos dados tipo CPF, CNPJ, Datas, etc… o que acaba deixando a classe anêmica, por isso que to querendo começar a estudar DDD, pelo que sei as regras em DDD ficam no model,(me corrijam se eu estiver errado), então em DDD, as o papel de um framework WEB por exemplo acaba nao sendo tao importante, certo? Ou to falando besteira!
[quote=danielbussade] Interessante as dicas. O que eu tava falando e que acho uma programação “feia” tipo tira da tela, passa tudo no construtor e da um em.persist(objeto) pro banco, fica uma coisa sem lógica nenhuma.
Mas nao tinha pensando no que você falou quando começa a interagir com o resto do sistema eh que a classe vai ganhando vida;
O maior problema disso tudo eh o seguinte, na maioria das vezes eu utilizo frameworks que fazem controle de acesso definidos por grupo, validação dos dados tipo CPF, CNPJ, Datas, etc… o que acaba deixando a classe anêmica, por isso que to querendo começar a estudar DDD, pelo que sei as regras em DDD ficam no model,(me corrijam se eu estiver errado), então em DDD, as o papel de um framework WEB por exemplo acaba nao sendo tao importante, certo? Ou to falando besteira!
Valeu[/quote]
Daniel,
acredito que se você já utiliza frameworks que atendem seu cenário, te garantem qualidade (com ou sem testes automatizados) e mantenham teu projeto fácil de manter você não precisa aprender DDD só porque é a moda do momento.
Geralmente nós temos o impulso automático de pichar o que não é DDD ou é orientado a banco de dados. O importante nisso tudo, antes de sair pichando, é verificar se, independente de modelagem e arquitetura, as práticas utilizadas atendem ao negócio e trazem a produtividade e qualidade esperada. Se meus clientes estão felizes e tudo vai bem (de verdade) pouco importa as práticas de engenharia utilizadas.
