| Autor |
Mensagem |
|
|
roger_rf wrote:
MWAdriano wrote:E aí pessoal? O Netbeans abandonou de vez mesmo o suporte as antigas aplicações Swing Application Framework?
Grato.
Você pode baixar um plugin para continuar a desenvolver aplicações SAF, mas a equipe NetBeans recomenda o uso da plataforma NetBeans em substituição à especificação SAF, que foi abandonada.
Entendi... A idéia é poder continuar a dar suporte a umas aplicações legadas em SAF, mas não desenvolver novas aplicações em SAF. As novas aplicações eu pretendo usar Netbeans ou o que estiver substituindo. Será possível fazer isso (manter ambos os suportes) com esse plugin ? Vc sabe o nome desse plugin e onde baixar e como instalar?
Grato!
|
 |
|
|
E aí pessoal? O Netbeans abandonou de vez mesmo o suporte as antigas aplicações Swing Application Framework?
Grato.
|
|
|
|
Jair Rillo Junior wrote:Adriano,
DDD não é uma receita de bolo que devemos segui-lá sem analisar o nosso cenário. No seu cenário, seu repository precisa de um método ADD e outro UPDATE? Se sim, manda bala em implementá-los, não há problema algum.
Uma dica é: entenda bem o Pattern Aggregate. Teoricamente, um Repository deve existir para o agregado raiz, os objetos "internos" dele podem/devem ser persistidos, alterados diretamente pelo raiz. Exemplo:
Supondo que no seu cenário o agregado raiz seja um objeto Cliente. Seu sistema também controla os Pedidos, que no caso pertencem à um cliente, assim sendo, Pedidos fica dentro de Clientes.
Clientes --(faz pedido)---> Pedido
Para persistir o Pedido, você não precisa, e na minha opinião não deve, ter um repositorio para Pedidos, pois você simplesmete faria "clientes.addPedido(pedido)".
Com Hibernate, teriamos um código assim mais ou menos
Note que no exemplo acima existe um repository apenas para o objeto agregato raiz.
Em alguns exemplos mais "radicais", você pode ter, como exemplo, objeto raiz SISTEMA, que tem apenas 1 valor que foi previamente inserido via INSERT direto na base de dados. Nesse caso, o sistema.addCliente, sistema.addProdutos, sistema.findClienteById().addPedido() e por ai vai.
Isso é só uma dica. Espero que tenha ajudado
Jair, seguinte:
Pelo que entendi de DDD e Repository, um repository em sua tradução para o nosso português representa um repositor e não um recipiente (esse seria o banco de dados ou arquivos) como alguns interpretam em alguns casos. Então o referido "repositorio" em OO deve representar um repositor do mundo real, ou seja, um cara (como se fosse uma pessoa, um profissional) responsável por guardar ou buscar um determinado objeto (ou um tipo de objeto) que será ou está guardado em um determinado local ou recipiente (SGBD). Como um funcionário que fica repondo produtos no estoque e retirando do estoque para encaminhá-lo a expedição. Não necessariamente algum funcionário contratado somente para exercer essa função, mas qualquer um que realize essa tarefa estaria exercendo, ao menos naquele momento, o papel de repositor, logo, o referido repository correto?
Sempre ouço que em OO devemos ao máximo representar o mundo real. Em tese, representar objetos do mundo real em objetos de programação pode ser um tanto subjetivo por depender muito do "ponto de vista". E depende do ponto de vista de cada um e pior, do seu próprio ponto de vista daquele dia (que pode ser diferente do de outro dia)...rs..
Se entendi bem, quando diz sobre o "agregate root" ser o cliente (que se entendi bem você refere-se a "Entidade" Cliente), este deveria guardar um pedido (outra entidade), por ser dele este pedido.
Pois bem, onde quero chegar? Porque um cliente deveria guardar um registro de pedido? Talvez, um cliente possa (ou até tenha que) fazer um pedido. Mas daí a ele ser responsável por guardar um pedido não seria delegar tarefa de um repositor a um cliente?
Grato!
|
|
|
|
Seguinte: Utilizo Hibernate como JPA 2.0 provider. Não uso o arquivo hibernate.cfg.xml, ao invés disso, uso o persistence.xml para configurar o Hibernate como JPA 2 provider.
Além desses frameworks, uso o Spring para IoC e DI e o Tomcat como servlet container.
Como preciso fazer log de erros de todo o sistema, escolhi o log4j para tanto.
Então coloquei a seguinte linha no meu web.xml
No arquivo /WEB-INF/log4j.properties, coloquei o seguinte conteúdo:
Só que eu rodo a aplicação e ele nem cria o arquivo /opt/tomcat6/logs/log.txt
Ele cria outros arquivos de log do Spring, mas esse ele não cria. Tem algo de errado no meu
raciocínio ?
Exemplo:
Quando estou rodando o sistema aqui, ele aborta a thread dentro de um DAO. Sei que é dentro dessa classe, pois acompanhei na console, danto mensagens na console para acompanhar até onde ele vai no processamento. Esse DAO faz uso do EntityManager e da API Criteria (JPA 2.0) para fazer construir uma consulta.
Cheguei na conclusão que ele para no seguinte código:
Independente do erro, eu precisaria tê-lo em algum log para saber de que erro se trata e resolver... Não sei nem qual exception ele está lançando...
Se alguém puder ajudar, agradeço muito.
[]s.
|
|
|
|
É chegado o momento da dor de cabeça.
Enfim, estamos a algum tempo implantando o Git aqui na empresa como controle de versão. Bom, para integrá-lo ao Netbeans 7 tem que instalar um benedito de um Plug-In que não funciona direito nem a pau!!...
Solução encontrada: Baixei uma versão do Netbeans recentíssima (7.1 Beta de desenvolvimento) onde já corigiram os bugs referentes ao Git e parece estar funcionando melhor.
Efeito colateral : Meus aplicativos legados que usam Swing Framework não funcionaram !!!
Mensagem do Netbeans 7.1 : O suporte do NetBeans oferecido à Estrutura do aplicativo Swing foi interrompido. Utilize o Netbeans 7.0 se desejar utilizar esta estrutura.
E agora? Como migarar meus aplicativos legados? Tem uma forma fácil ? Ou tenho que escreve-los denovo?
Sei que um dia isso ia acontecer, afinal já tinha uma mensagem do Netbeans avisando isso desde a versão 6.9 (se não me engano)... Mas e agora???
Se alguém tiver uma luz...
[]s.
|
|
|
|
Opa... legal!
Mas será que não tem como fazer no Netbeans? É que já estou mais acostumado com essa IDE e não queria ter que mudar, entende ?
[]s.
|
|
|
|
Pessoal, alguém sabe como fazer para criar um gerador de codigo-fonte no Wizard de criação de codigos do Netbeans? Vou explicar melhor:
O Netbeans cria automaticamente, a partir da engenharia reversa do banco de dados, as entidades, metadados e os controllers (DAO) do projeto. Ele cria os codigos fonte de cada classe, economizando tempo, evitando digitação repetitiva e desnecessária em muita coisa.
Gostaria de criar uma opção automática no Netbeans (escrever, programar essa opção) para que a partir das entidades já existentes em determinado pacote, ele criasse os objetos DTO que serão alimentados para transmitir os dados entre o servidor de aplicação e a View (estou usando Swing). Quero criar um Wizard que ele pergunte para o usuário onde está o pacote com as entidades e a partir dessas entidades, dando a opção de escolher quais entidades e quais os respectivos atributos serão copiados da entidade, ele deve criar (em outro pacote também escolhido) objetos tipo DTO (data transfer object) para cada entidade. Isso facilitará muito a criação das aplicações nos moldes que estamos trabalhando, aumentando muito a produtividade. Portanto, se não existe essa opção previamente criada no Netbeans, gostaria de criá-la e depois compartilha-la, mas não tenho a menor ideia nem por onde começo... Nunca fiz um gerador de códigos-fonte java, muito menos a partir de um código já existente (vasculhando o mesmo), e por isso nem imagino que API usar para isso e como usa-la. E nem como fazer para embutir isso no Wizard do Netbeans, o que aumenta minhas dúvidas.
Alguém me ajuda?
[]s.
|
|
|
|
YvGa wrote:
Nao vejo porque a ideia do Abel fere a normalizacao. Implementar tudo numa tabela enorme é que fere.
O caso que voce descreveu eh uma forma comum de implementacao de relacionamento um-para-um, muito mais comum do que heranca quando se trata do modelo relacional.
O que você entende por normalizar o modelo relacional? Implementar tudo em uma tabela gigante realmente não é adequado, e eu não sugeri isso em momento algum. Sugeri a a normalização do modelo relacional e isso pressupõe entender o problema e dividir em entidades diferentes, implementando-o mais próximo do mundo real. O Modelo-Entidade-Relacionamento pressupõe desenhar como as entidades se relacionam, e isso pode ser quebrado aprofundando o problema e não simplesmente quebrando uma mesma tabela em três partes. Dados pessoais, você pode ter cada dado quebrado e relacionado com a pessoa, assim como dados médicos ou profissionais, em vez de uma tabela com tudo dentro ligada a outra tabela. Quando você para para reunir muitos dados em uma tabela você está limitando a normalização. Eu sugeri justamente o contrário disso.
Muita gente reclama sobre as limitações do modelo relacional, mas acho que se a gente procurar entender melhor o que propõe, vai perceber que existe possibilidade de implementar quase tudo que se pode fazer em um modelo OO. Só dá mais trabalho por não ter ferramentas prontas, e é isso que eu estou propondo.
[]s.
|
|
|
|
AbelBueno wrote:
MWAdriano wrote:Abel, não se trata do mesmo caso! Pense bem: Na tabela Aluno_Professor, a PK é composta por 2 (duas) colunas (AlunoId e ProfessorId). Não é a mesma chave de nenhuma das outras tabelas. No caso da tabela Aluno a PK seria composta da coluna AlunoId (uma hipotese) e no caso da tabela Professor a PK seria composta pela coluna ProfessorId.
O segundo caso que você passou, no caso de endereço, Endereço tem em como parte de sua PK a coluna PessoaId. Mas não sua PK não é a mesma da tabela Pessoa, apenas é composta por uma FK que é PK da tabela pessoa. É diferente.
A herança só é identificada quando há uma relação de chaves PK-FK-PK direta. Ambas as PKs tem que serem chaves compatíveis e uma tem que ser FK da outra. Assim, não há erro para identificar uma herança.
Que achas?
[]s.
Ah, me desculpe...agora entendi o que você quis dizer.
Tem razão, nesta condição imagino que o relacionamento pode representar herança.
Porém, ainda assim, há situações onde isto pode falhar.
Já vi casos em que uma tabela é quebrada em mais de uma, para agrupar dados relacionados.
Por exemplo, uma tabela de pessoa pode ser quebrada em DadosPessoais, DadosMedicos, DadosProfissao e assim por diante...
Neste caso seria um caso de composição e não herança... (aliás...muitas vezes herança é um caso de composição)
Bom, eu acho que nesse caso há falta de normalização. Daí, sim, uma questão de estratégia de modelagem. Posso imaginar alguns motivos que levaria alguém a modelar assim, mas não considero o ideal, nem de longe.
Remetendo-me as aulinhas de DER e MER ainda em 94, a normalização extrema do domínio "seria" o melhor dos mundos para representar o mundo real em um modelo relacional, não fosse a limitação do hardware para conseguir tocar grandes bases em SGDBs. Mas lembrando denovo, essa limitação existia em 94, quando eu usava um 486DX 50Mhz com 8MB de RAM para tocar Windows 3.1 Será que essa limitação ainda é preocupação hoje ?? Acho que não... 
[]s.
|
|
|
|
moscoso.dev wrote:
MWAdriano wrote:Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho.. Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela... Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!
Sinceramente, nunca vi uma situação onde a chave primária de uma tabela é uma chave estrangeira apontada para a chave primária de outra tabela, nem acho que isso seja considerado boa modelagem relacional.
E como você modelaria um caso onde você tem Funcionários, Clientes, Fornecedores e Pessoas ? Cada um teria uma PK diferente? Você acha que isso seria uma boa abordagem para representar o mundo real ?
[]s.
|
|
|
|
AbelBueno wrote:
MWAdriano wrote:Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho.. Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela... Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!
Muitas relacionamentos NxN não entram nesse caso?
Por exemplo: uma tabela Aluno, uma tabela Professor e a tabela Aluno_Professor de relacionamento.
Sem falar que isso ocorre em muitos casos de chave composta:
Por exemplo: tabela Pessoa, tabela Endereco, onde a pk de endereço é um sequencial + id da pessoa
Nestas situações não vejo que há herança.
Abel, não se trata do mesmo caso! Pense bem: Na tabela Aluno_Professor, a PK é composta por 2 (duas) colunas (AlunoId e ProfessorId). Não é a mesma chave de nenhuma das outras tabelas. No caso da tabela Aluno a PK seria composta da coluna AlunoId (uma hipotese) e no caso da tabela Professor a PK seria composta pela coluna ProfessorId.
O segundo caso que você passou, no caso de endereço, Endereço tem em como parte de sua PK a coluna PessoaId. Mas não sua PK não é a mesma da tabela Pessoa, apenas é composta por uma FK que é PK da tabela pessoa. É diferente.
A herança só é identificada quando há uma relação de chaves PK-FK-PK direta. Ambas as PKs tem que serem chaves compatíveis e uma tem que ser FK da outra. Assim, não há erro para identificar uma herança.
Que achas?
[]s.
|
|
|
|
Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho.. Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela... Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!
|
|
|
|
|
Pois eh Edson. Eu imagino que seria isso também.. Acho que isso deveria estar nas ferramentas porque imagino que pelo menos em 90% dos casos em que uma tabela tenha como sua chave primária uma chave estrangeira importada da chave primária de uma outra tabela, ela será extendida desta tabela.. Não consigo imaginar outra hipotese. Então a ferramenta deveria detectar isso e dar essa opção para você escolher no momento da importação. Mas na minha visão isso é muito óbvio! Vc saberia dizer porque isso não está implementado? Ou se está, onde está?
|
|
|
|
Desculpem se estou tentando abrir um assunto que já tenha sido muito discutido e eu não saiba. Se esse for o caso, peço que uma alma caridosa me indique o link para a discussão, pois preciso muito estudar isso, urgente.
No meu ponto de vista esse é um assunto muito relevante para quem vai desenvolver um sistema, seja ele qual for. Quero falar sobre a estratégia utilizada para se criar entidades em um modelo de domínio. Pelo que eu saiba, salvo grotesco engano, devemos trabalhar para tirar o máximo de proveito dos recursos de OO para fazer com que as entidades representem o domínio do negócio de forma mais próxima da realidade possível. Pois bem, caso eu esteja enganado, peço que alguém me corrija. Mas se isso representa a verdade, vou apresentar o seguinte senário, onde tenho entidade Systemuser, que representa um usuário do sistema e tenho as entidades Employee, Customer e Vendor. No meu entendimento, todos essas entidades estenderiam direta ou indiretamente de uma entidade Person, pois no mundo real elas representam a entidade (pessoa), apenas com caracterísitcas a mais. Por exemplo, um cliente e um fornecedor são pessoas. O funcionário também, mas podemos considerar que o usuário do sistema, por sua vez, é um funcionário.
Acredito que nessas situações mencionadas acima, a herança representaria muito melhor o mundo real do que o encapsulamento e convido os amigos a pensarem comigo. É diferente dizer que um funcionário é uma pessoa e dizer que um carro tem um motor. O encapsulamento representa muito melhor o segundo cenário.
Quando a chave primária de uma tabela é uma chave estrangeira apontada para a chave primária de outra tabela, entende-se automaticamente que uma entidade é uma extensão da outra. E não consigo imaginar diferente, a menos que haja uma mudança de conseito que eu não esteja entendendo.
Todavia, ferramentas IDE de criação automática de entidades através de JPA, como Netbeans ou Eclipse, quando solicitado para gerar entidades automaticamente com base em um banco já existente, o mesmo não cria as entidades extendendo uma das outras. Ele cria como objetos encapsulados em atributos. Alguém saberia dizer porque?
E se meu raciocínio está errado, alguém poderia me ajudar a ver isso?
Grato.
|
|
|
|
fenix.cwb wrote:Olá Pessoal, preciso que um JTextArea Seja atualizado em tempo real, mas ela só atualiza no final do processamento.
Gostaria que atualizasse a cada linha, mas não ta indo.
Tente o seguinte:
Deve funcionar...
E não esqueça de colocar limitadores de linha (CR+LF) no final de cada linha, senão vira uma linguiça sua String.
[]s.
|
|
|
|
|
|