| Autor |
Mensagem |
|
|
louds wrote:E ai você estaria implementando um framework de ORM, certo?
Nem tanto...
Eu acho que seria ótimo poder navegar livremente por um grafo de objetos em uma interface gráfica sem se preocupar em pré inicializar cada um deles.
Imagine que você tenha dados hierárquicos e queira mostrá-los em uma árvore em que todos os nós aparecem fechados inicialmente. Aí conforme você vai clicando nos sinais de [+], por exemplo, os nós vão se expandindo e acessando objetos associados que vão sendo recuperados automaticamente.
Algo assim não representa um framework ORM completo, é apenas uma estratégia de recuperação de objetos mais conveniente que poderia ser implementada usando AOP e/ou proxies dinâmicos que talvez pudessem ser colocados no lugar das associações lazy automaticamente pelo EJB3 ...
|
 |
|
|
Eu penso mais ou menos no seguinte:
Se houvesse como fazer com que o conteúdo da associação fosse algum tipo de proxy criado por mim, eu poderia implementar qualquer algoritmo para a recuperação do objeto associado, inclusive um código que invocasse algum session bean que recuperasse ele.
|
|
|
|
|
Se o cliente fosse Swing valeria a pena conhecer a biblioteca Binding do JGoodies. Pode ser encontrada no java.net.
|
|
|
|
Olá
Comecei a estudar EJB3 recentemente. Estou testando com JBoss 4.
Alguém mais já fez algum teste interessante ou protótipo?
No momento, eu estou tentando descobrir se é possível montar alguma estratégia para que "detached" entity beans possam fazer lazy loading de associações quando chamarmos o método getXxxx correspondente na aplicação cliente (em outra VM).
Idéias são bem vindas.
|
|
|
|
Meu presente acabou de chegar. 
Muito obrigado Umlauf!! Adorei o CD/DVD do Cold Play!!
|
|
|
|
vamorim wrote:Acabei de receber meu exemplar do livro Pai Rico, Pai Pobre.
Valeu, Gabriel (gcobr)! Abração!! Gostei muito (MUITO) da mensagem.
Fico muito feliz que tenhas gostado, dentre as suas sugestões iniciais eu escolhi este porque também tenho um exemplar que já li e adorei.
 Já o meu presente, ainda estou esperando ... espero que não tenha havido nenhuma confusão na entrega, pois os Correios aqui no sul as vezes deixam a desejar.
|
|
|
|
Feliz Natal Vinci!
Seu presente já está a caminho. Embarcou no sábado com destino a Viçosa!
|
|
|
|
Caros amigos
Não tenho grande experiência no desenvolvimento de aplicações Web com Java. Me dedico mais a um grande projeto que envolve J2EE mas com uma interface Swing ...
Bem, recentemente desenvolvi uma pequena aplicação usando JSP c/ scriptlets. Usei o Hibernate para acessar uma base de dados Firebird e implantei esta aplicação em um data-center, porque na verdade ela é parte do site de uma determinada empresa ..
Bem, acontece que quando a aplicação roda no servidor deste hospedeiro (que é a HostLocation de SP) todos os caracteres especiais da língua portuguesa (ç, á, ã, etc..) que estão na base de dados e são usados nas JSPs estão sendo trocados por "?". Os caracteres das strings fixas dentro das páginas ficam normais.
Porém isto só está acontecendo quando a app roda neste servidor especificamente. Na minha máquina funciona sem problemas.
Então como se trata de um data-center, eu não tenho acesso suficiente a máquina para debugar a aplicação por exemplo.
Aí, eu estou tentando imaginar como resolver o problema. Considerando que:
* A base dados tem charset NONE
* Não coloquei nenhuma configuração/declaração relacionada a charset nem a locale nas JSPs
* Não acho que haja algum tipo de configuração de charset possível de se fazer no Hibernate
Então, se alguém tiver alguma idéia, agradeço.
Obrigado,
Gabriel.
|
|
|
|
Caros amigos
Por acaso alguém já hospedou alguma aplicação Java (Servlets/JSP) com a HostLocation de SP (também conhecida como Knal)?
(www.hostlocation.com.br)
Gostaria de ouvir comentários a respeito dos serviços desta empresa ...
Saudações, Gabriel.
|
|
|
|
Caros Amigos (e Moderador)
Me cadastrei no www.amigosecreto.com.br mas minha participação ainda não foi liberada.
Peço gentilmente ao moderador que o faça.
Muito obrigado,
Gabriel.
|
|
|
|
Luca wrote:Mais uma vez vou citar o Banco Postal.
 View - uma applet que apenas e tão somente captura dados, faz sua consistência e os envia para o servidor. É toda componentizada e usa diversos design patterns. Só aqui são mais de 1200 classes.
Controller - servlet que intermedeia as transações traduzindo para o formato ou protocolo adequado à camada adjacente.
Model - onde ficam as regras de negócio na verdade é composto de várias camadas sendo algumas em Brasília e outras em SP. Não foi feito em Java.
As transações trafegam usando protocolo web (http/https) entre as camadas só com seus dados, não são objetos serializados.
Avaliamos uma arquitetura assim também para nosso caso. Porém seria necessário muito código para passar as informações dos objetos para HTTP e também para apresentá-las na interface caso não fossem objetos.
Isso porque não poderiamos fazê-lo automaticamente, seria necessário implementar um algorítmo específico para cada formulário da interface.
A não ser que fossem enviados via HTTP objetos serializados em XML, mas aí seria quase o mesmo que serializar direto.
|
|
|
|
Gostaria ainda de acrescentar que no último JustJava, Michael Santos fez uma belíssima apresentação intitulada: Simplicidade, Produtividade, Testabilidade e Escalabilidade com J2EE, AOP e Rich Clients.
Nela foi feito um "estudo de caso" de um cliente da Summa para o qual a produtividade era um dos principais requisitos do sistema, já que o desenvolvimento seria seguido pela equipe do próprio cliente.
A aplicação demonstrada também não usa MVC entre a visualização (nesse caso em Thinlet) e o modelo (no servidor de aplicação), e nem por isso o seu design é ruim.
Os slides devem estar disponíveis para download.
|
|
|
|
O que determina lucro/prejuízo em uma emrpesa, seja ela qual for, é uma série de fatores, dentre os quais a qualidade de um produto oferecido e o preço. Alguns investem em rpeço, outros em qualidade.
Sem dúvida, qualidade e preço são fundamentais. O design deve sempre buscar um meio termo entre produtividade, qualidade e preço. Já que este último, o preço, vai ser diretamente proporcional ao tempo gasto no desenvolvimento.
Produtividade é uma métrica itneressante. Primeiro que ninguém define o que é ser produtivo ou não. produtividade é contar linha de código/dia? Telas produzidas /dia? (se for isso, ferrou porque trabalho com back end, devo contar mensagens de log/dia).
Eu defino produtividade como: Entregar para a empresa cliente um produto que atenda suas necessidades em um prazo que seja curto o suficiente para que esta empresa possa gerar o maior lucro possível em decorrência de sua implantação, justificando o investimento realizado.
Novamente 'produtividade' é palavra curinga: serve para tudo! o que tem a ver o sistema ficar pronto rápido ou demorar (medidas completamente relativas, aliás) com ele ser adaptável ou não?
Me refiro a produtividade na realização das adaptações. Essa é a relação.
Desculpe, mas isso aí foi nada com coisa nenhuma.
Produtividade e Design? linahs gerais? O que você quis dizer com isso?
Rescrevendo: O design deve, além de atender todos os requisitos de negócio da aplicação, buscar a melhor produtividade possível para sua implementação.
Acho que houve uma confusão aqui, de qualquer modo se você está com problemas com este escopo dentro de um ambiente de servidor, sua aplicação provavelmente está mal projetada. Camadas. Elas servem apra isso.
Em momento algum eu disse que estou com problemas. Muito pelo contrário, a arquitetura pela qual optamos atende muito bem a todos os requisitos (inclusive ao da produtividade). E está sim dividida em camadas. Apenas não existe MVC entre a camada de visualização (Swing) e o modelo (no servidor de aplicação).
Por outro lado, temos MVC, na implementação da camada de visualização. Objetos que recebem (ou apresentam) dados do usuário são o modelo para formulários e demais controles visuais.
Não estou entendendo seu ponto. O que MVC tem contra isso? A boa definição de interfaces de negócio elimina muitos dos problemas que você poderia ter com esses requisitos, se você usar Swing, JSP, Struts, WebWork, SOAP, RMI... não importa!
O MVC não tem nada com isso. Meu comentário foi para demonstrar como a apresentação dos dados do exemplo em um único formulário é um requisito importante para o sistema, bem como a execução de processos de negócio não reversíveis somente após um "OK" do usuário.
Mesmo hoje existem sistemas (e muitos) em que COBOL é verdade.
Você sugere então que a interface deva ser projetada visando primordialmente padrões de projeto sem levar em consideração a usabilidade e agilidade de que o usuário precisa?
Ou que talvez seja mais prático implementá-la em COBOL?
Mas não há qualquer motivo para seu formulário processar regra de negócio.
Você tem toda razão. O formulário realmente não processa nenhuma regra de negócio. Todo o processamento feito tem como objetivo impedir erros na entrada de informações, ainda que a implementação seja mais complexa.
Se você realmente precisa fazer uma transação batch (e se manter na década de 90, evitando tudo que um sistema distribuído tem de bom) você vait er este problema, mas se resolver entrar no século XXI vai poder utilizar Proxies leves para representar suas dez mil listas, e fazer seu cliente manipular apenas aquilo que realmente precisa, trazendo e enviando informações do/ao servidor apenas quando necessário.
Aí é que está. No meu exemplo, o cliente precisa manipular todas as minhas "dez mil listas". Sem exceções. Nenhuma informação desnecessária é enviada do servidor para o cliente.
E também utilizo proxies em outros casos onde apenas um parte do grafo de objetos interessa.
Eu até agora não entendi Você disse que MVC não é produtivo, que não se aplica bem em arquiteturas com três camadas.
O que eu disse é que MVC entre um domínio de objetos no servidor de aplicação e uma interface Swing é algo complexo, e que a implementação disso pode ser pouco produtiva, pois pode envolver DTOs e argumentei a respeito.
Em contra partida, MVC num escopo menor como a interface pode ser muito útil.
Cabe a cada desenvolvedor julgar o que é melhor para seu caso.
|
|
|
|
Se estamos falando de sistemas grandes e muito distribuídos, a complexidade afeta a produtividade, mas distribuir sua aplicação tem benefícios que nenhum 2-camadas tem.
'Produtividade' é um termo de marketing que as pessoas cismam em usar tecnicamente. Delphi 'é mais produtivo' que Java. VB também. Que tal?
...
É besteira querer os benefícios sem pagar o preço, e o preço de um bom design é gastar algum tempo..bem, fazendo o design!
...
Você precisa definir melhor suas interfaces, resposabilidades e camadas.
"Produtividade" não é só um termo de marketing. É a produtividade da empresa de software para a qual você trabalha (suponho) que vai determinar se ela terá lucros ou prejuízos.
Além disso, sem um determinado nível de "produtividade" você pode não conseguir acompanhar o ritmo de alterações necessárias no sistema.
Mesmo sistemas bem desenhados estão sujeitos as mais brutais alterações. De fato, alguns já são projetados prevendo isso.
É indiscutível que o design deva ser bem pensado, e que dele dependerá o sucesso da aplicação. Por isso a "produtividade" deve ser um requisito importante a se considerar ao se definir as linhas gerais da aplicação.
Pelo seu escopo, eu acho que você está fazendo sua aplicação (de exemplo) cliente trabalhar demais, e fazer operações em lote, para depois enviar o resultado. O tempo do batch já passou, e você conseguirá problemas terríveis de acesso concorrente e transacionamento desta forma.
Os problemas de acesso concorrentes e transacionais são todos resolvidos pelo servidor de aplicação. É para isso que ele serve, dentre muitas outras coisas, é claro.
No exemplo dado, a grande quantidade de informações entradas pelo usuário será conferida na tela antes do click no botão "Salvar" por exemplo. Os processos de negócio desencadeados no servidor de aplicação a partir daí nem sempre são facilmente reversíveis. Isso justifica a implementação descrita, que permite que o usuário corrija entradas erradas, minizando erros e processos corretivos.
Imagine o quão penoso pode ser recalcular o valor médio de um produto que sofre 500 mil movimentações de estoque todos os dias só porque um usuário informou equivocadamente o valor de um item no exemplo da Nota Fiscal que comentei anteriormente. É preciso minimizar as chances de que esse tipo de problema ocorra, fazendo com que as informações vindas da interface contenham o mínimo possível de erros e a implementação de formulário sugerida acima atende bem a tal requisito.
Codificar isso num formulário é se manter na década de 90 para sempre. A arquitetura cliente/servidor é defasada, e mesmo essa arquitetura é má utilizada quando formulários executam regras de negócio, existem alternativas ainda dentro deste paradigma.
Mesmo hoje, existem sistemas (e muitos) em que isso é na verdade um requisito para a interface. Muitos processos industriais informatizados hoje são baseados no conceito de uma "especificação técnica" do produto que é usada como base para a produção. Cada vez que a indústria recebe um pedido do produto em questão a estrutura é duplicada e nela são alterados todos os pontos da especificação necessários para customizar o produto as necessidades do cliente (geralmente isso é feito por um engenheiro de produção qualificado).
Então devido a grande entrada de dados o formulário precisa oferecer ao usuário o maior número de facilitadores possíveis, como por exemplo o auto-preenchimento de campos com informações padrão ou o cálculo automático de algum valor que o usuário poderia deixar como está ou alterar para outro.
Nesse exmplo, manter essas informações juntas em um formulário não é uma questão de design e sim um requisito do sistema. Seria desconfortável para o usuário se essas entradas fossem feitas em formulários separados ou até mesmo em algum tipo de assistente ou algo do gênero.
|
|
|
|
pcalcado wrote:
Não necessariamente. Uma estrutura bem distribuída oferece interface entre componentes de negócio e apresentação, a apresentação MVC utiliza esta interface como Model.
Você tem alguma idéia de como criar tal interface de maneira produtiva?
Imagine que você tem que desenvolver um formulário para entrada de todos os dados de uma Nota Fiscal recebida por uma indústria em um sitema ERP. Imagine que o objeto NotaFiscal tem uma coleção de itens e que para cada item desta coleção existem mais duas coleções e siga assim até totalizar uns 5 níveis de detalhamento. Imagine que esse detalhes devam ser informados no formulário e que ao final de tudo o usuário possa clicar em um botão "Salvar" que além de enviar o objeto para persistência no app server vai, através de Session Beans, gerar toda a movimentação de estoque necessária para o sistema e executar mais uns 10 processos em várias outras áreas do sistema (usando todos os detalhes informados) em decorrência da entrada dessa Nota Fiscal.
Um cenário assim não seria nenhum absurdo em um sistema de gestão integrado de uma empresa de grande porte.
Codificar isso em um formulário já é bastante trabalhoso e codificar algo mais entre as camadas me parece ainda mais.
|
|
|
|
|
|