| Autor |
Mensagem |
|
|
Tem uma opção, que junta boa parte do que todos falaram, seria uma divisão de módulos(sub-sistemas, projetos do eclipse, etc.) algo assim :
dominio-geral
dominio-especifico-emissão-NF
dominio-especifico-declaração-NF
web-gera-NF
desktop-emite-NF
Aí vamos supor um exemplo de Endereço como vc citou, vou criar alguns atributos de mentira ai só pra exemplificar :
Essa aqui tá no "domínio-geral", e tem seu próprio mapeamento.
Essa aqui tá no "domínio-emissão-nf" e também tem seu próprio mapeamento, e a classe de composição que tá dentro dela não tem um novo mapeamento, ela usa o do outro módulo.
Eu tenho uma estrutura parecida com essa, mas eu uso o maven, então ele me ajuda bastante, pois tem resources que são compartilhados também, ele já explode pra mim dentro as dependências e me adianta um lado, mas vc consegue fazer com as dependencias de projetos do eclipse que vc comentou.
Assim vc reaproveita o código, mas só tem que ver se o seu domínio continua representando a visão idealizada pelo cliente/analista. As vezes não vale a pena tanto aproveitamento se tudo ficar rebuscado.
|
 |
|
|
Nesse cenário, onde só muda o frontend, será que não compensa vc ter somente módulos separados ?
O que eu quero dizer ?
Criar um módulo onde está todo o seu domínio (entidades da declaração e emissão da nota), e dois outros módulos que seriam sua GUI, um para Web e outro para Desktop.
Você não cria uma complexidade particionando seu domínio, e ainda por tabela consegue separar bem sua interface, deixando livre para no futuro implementar telas que estão em Web para Desktop e vice-versa, sem grandes traumas, afinal seu domínio está em outro módulo.
[]´s
|
|
|
|
Olá !
Você pode compartilhar o que é comum através de composição, onde nessas entidades onde realmente é comum o mapeamento é o mesmo, e vc cria outras classes com os atributos específicos e mapeamentos específicos.
Só toma cuidado com o cache do hibernate nessas duas aplicações hein, é fácil de dar zica.. muito fácil !! 
[]´s
|
|
|
|
Concordo com vc ! 
Tb acho estranho esse lance "uma pessoa se auto salva a si mesma"... Todo o caso é que se formos levar OO ao pé da letra, isso seria o correto, pq todos os comportamentos possíveis para a Pessoa estariam dentro da própria classe(mesmo que implementada através de composição).
Isso realmente dá muitas interpretações !
E viva a diversidade, pq senão estavamos todos programando em Assembly !! 
|
|
|
|
Acho que eu entendi
Pensando na implementação...
O Repositorio de pessoas, necessáriamente conheceria a classe CPF, correto ?
|
|
|
|
Na verdade o padrão diz que o objeto tem que saber como "se persistir" mas acho que colocar regras de mapeamento em banco, ou detalhes maiores de persistência dentro de um objeto de negócio já começa a causar aqueles nossos queridos patterns BFG(Big Fucking Class)
Essa separação em repositórios é para ter as vantagens OO mesmo...
A vantagem do AR é não ter que ficar instânciando outras classes para persistir, vc só conhece seu objeto de negócio, tudo fica ali na mão onde estiver a classe de negócio vc tem as operações necessárias.
Lembrando que tb não sou um grande fã de AR, mas com certeza é interessante separar essas responsabilidades sim...
|
|
|
|
Com certeza !!
Acho que não consegui um exemplo muito bom devido à pressa...
Mas se por acaso eu precise pesquisar pessoas baseadas em um CPF(já que ele é um atributo, como nome, altura, peso, etc..), mesmo que eu ja tenha ele inteiro, então eu passaria um objeto da CPF como parâmetro certo ?
Aí acho que caíriamos no mesmo problema não é ?
|
|
|
|
Acredito que um pouco é gosto/opinião mesmo...
Pois em um cenário hipotético a seguir :
Tenho um atributo da classe Pessoa, que é o cpf, onde ele também é uma classe, pois tenho algum tipo de comportamento específico lá, e preciso fazer uma busca de pessoas com cpf iniciando em 268. Essa busca estará implementada no repositório do CPF certo ? Então dentro do objeto pessoa terei uma referência à um segundo repositorio... ou a busca estará no repositório da pessoa, que irá referenciar o repositório do CPF, de um jeito ou de outro aumenta o acoplamento.
E tem outro cenário também :
Imagine que existam várias buscas específicas, com vários parâmetros específicos(listPessoasAtivas,listPessoasDoDeptoX,listPessoasAposentadas, etc..), essas buscas serão vários métodos listXXX() na classe Pessoa, ou irei acessar o repositório direto utilizando esses métodos, então fico com dois lugares para recuperar dados de pessoa.
Nas duas situações não acho muito legal, dá margem à diversas interpretações de como fazer, isso em uma equipe grande vira um pandemônio ! 
Já vi várias abordagens para esses cenários, uns melhores outros piores, eu particularmente não achei algum que eu gostei.
Mas é somente minha opinião, pq sei de muita gente que odeia ter aquele padrãozinho XXXService para uma coisa, ou YYYService para outra e os dados em objetos burros sendo transportados por um lado e outro...
[]´s
|
|
|
|
Pode não ter concorrência, mas com certeza outros problemas podem surgir, que com certeza já foram resolvidos por qualquer banco de dados, se a idéia é que fique leve, pq não utilizar hsqldb ou derby ?
Eles sobem com sua aplicação e vc tem todas as facilidades de um banco de dados, será que não compensa repensar esse armazenamento ?
Digo isso, pois já tive problemas com essa história de armazenar em Xmls, sempre surgem surpresas !
[]´s
|
|
|
|
"Em casa de ferreiro, espeto é de pau"
Ditados que as vezes fazem jus à sua existência
|
|
|
|
Cai SOA pra burro !! Todas as APIs de manipulação de XML(JAXB,JAXP,JAX-WS,etc...), protocolos, segurança, tudo de SOA com WebServices...
Outro item que cai bastante é sobre certificação digital, a API java.security.*, as novas APIs que surgiram com JEE 5.0
Isso na minha prova pelo menos..
|
|
|
|
Parabéns à ambos !!
Passei tb !
Mas para falar a verdade, não achei que ela avalie bem não... pois muito do projeto, tendencia vc à usar EJB, e coisas da especificação, que na vida real muitas vezes não escolheríamos !
Mas naquelas, se é pra ser um SCEA que manja de soluções realmente voltadas só para a SUN, aí acho que vale...
|
|
|
|
Meu medo do RoR é ele sair do nicho que o saoj comentou, aplicações mais simples e que não exigem alta disponibilidade ou processamento distribuído e cair para sistemas pesados de verdade, pq teve um carinha no desenvolvimento lá que gostava RoR e fez.
Pq aí sobra pra dar jeito nesse tipo de projeto, problemas de performance, disponibilidade, etc.. e aí quando falamos que tem que refazer os GPs vão dar xiliques...
|
|
|
|
Uma coisa eu concordo com o Rod, se as duas tecnologias ficarem brigando, logo, logo vamos ter Rails em todo canto..
Agora que o pessoal começou a saber java de verdade, e os projetos estão saindo melhores, não sei se seria interessante pegar a galera e reiniciar com uma nova linguagem, que na minha opinião, não acrescenta tanto para justificar sua existência... mas claro isso é a minha opinião...
|
|
|
|
Acredito que a ofuscar o código já protege o suficiente, pois se o cara vai ficar lendo aquele código que a descompilação gera, então ele vai ler assembly que é gerada em outras linguagens...
Um produto feito em java que é vendido e bastante, é o Oracle Applications, a partir do 11i é feito em Swingão !
|
|
|
|
|
|