Arquitetura de sistema Swing

50 respostas
paulohbmetal

Salve Brothers of Java!!

Gostaria de de discutir a forma em que estou construindo meu sistema Swing em camadas.

Bom, a tempos atrás estava eu procurando uma forma de fazer o mapeamento objeto-relacional
até que me deparei com este artigo
e gostei da forma de mapeamento.

Bom, mas a partir desta forma de mapeamento, eu comecei a bolar uma forma de para melhor me adaptar.
Vou colocar um exemplo, para que fique mais clara a forma em que estou desenvolvendo:

Por exemplo no cadastro de usuários.Tenho minha classe(bean) Usuario:

public class Usuario{
	private int iCodigo;
	private String sLogin;
	private Sring sSenha;
	
	//Métodos get set simples
	//...
}

uma interface para o DAO:

public interface IUsuarioDAO{
	void incluir(Usuario usuario) throws MinhaExcecao;
	void alterar(Usuario usuario) throws MinhaExcecao;
	void excluir(Usuario usuario) throws MinhaExcecao;

	boolean valida(Usuario usuario) throws MinhaExcecao, UsuarioNaoEncontradoException;
	///...
}

o DAO:

class UsuarioDAO implements IUsuarioDAO{

	private static UsuarioDAO usuarioDAO = new UsuarioDAO();
	
	private UsuarioDAO{
	}

	public void incluir(Usuario usuario){
		.
		.
		.
	}

	public void alterar(Usuario usuario){
		.
		.
		.
	}

	public void excluir(Usuario usuario) throws MinhaExcecao{
		.
		.
		.		
	}

	public static UsuarioDAO getInstancia(){
		return usuarioDAO;
	}

	//...e por aí vai...
}

Minha classe de negócio,

public class CadastroDeUsuarios{
	private IUsuarioDAO usuarioDAO = FactoryUsuarioDAO.getInstancia().getDAO();
		
	public void gravar(Usuario usuario){
	
	}
	
	public void excluir(Usuario usuario) throws MinhaExcecao{
		usuarioDAO.excluir(usuario);
	}

}

E minha Factory:

class FactoryUsuarioDAO{
	private static FactoryUsuarioDAO factoryUsuarioDAO = new FactoryUsuarioDAO();

	private FactoryUsuarioDAO(){
		//Carrega informações de qual DAO deve ser carregado em um properties ou XML
	}

	public IUsuarioDAO getDAO(){
		//faz os testes e retorna a instancia a ser usada
		return UsuarioDAO.getInstancia();
	}

	public static FactoryUsuarioDAO getInstancia(){
		return factoryUsuarioDAO;		
	}
}

Bom daí o que faço:

No meu view(JFrame, JInternalFrame e etc...), instancio um objeto do tipo CadastroDeUsuarios(que aplico as regras de negócio), que por sua vez obtém através do Factory o DAO que faz as operações no banco.Por enquanto não estou trabalhando com ele distribuído, mas caso venha, crio uma interface para a classe de cadastro(Business).

Bom, as vezes acho que estou escrevendo demais, mas me parece que é assim mesmo.Gostaria que dessem suas opniões para discutirmos se
está bom e se não qual é a melhor forma.

O que acham?! :roll:

Bom, espero ter sido claro, e espero críticas também.

A Paz!!

50 Respostas

paulohbmetal

Ninguém?! :shock:

Pirei, pensei que aqui seria o fórum que teriamos mais discussões…

A Paz!!

Betinhum

paulohbmetal:
Ninguém?! :shock:

Pirei, pensei que aqui seria o fórum que teriamos mais discussões…

A Paz!!

Tbm estava esperando a discussão :roll: . Já vi aqui e no JavaFree esse tipo de assunto dar briga :twisted: . Cheguei a fazer o diagrama de classes e usar o “Acompanhar este tópico”. :?

Gostei da sua arquitetura, entretanto estou aguardando outras idéias. :wink:

Fui!

paulohbmetal

Betinhum:
paulohbmetal:
Ninguém?! :shock:

Pirei, pensei que aqui seria o fórum que teriamos mais discussões…

A Paz!!

Tbm estava esperando a discussão :roll: . Já vi aqui e no JavaFree esse tipo de assunto dar briga :twisted: . Cheguei a fazer o diagrama de classes e usar o “Acompanhar este tópico”. :?

Gostei da sua arquitetura, entretanto estou aguardando outras idéias. :wink:

Fui!

Pois é.Estranho não?!Mas eu não estou querendo arranjar encrenca, e se vierem críticas aceito numa boa.

Mas parece que a galera saturou… :lol:

Vou esperar.

A Paz!!

Betinhum

paulohbmetal:
Betinhum:
paulohbmetal:
Ninguém?! :shock:

Pirei, pensei que aqui seria o fórum que teriamos mais discussões…

A Paz!!

Tbm estava esperando a discussão :roll: . Já vi aqui e no JavaFree esse tipo de assunto dar briga :twisted: . Cheguei a fazer o diagrama de classes e usar o “Acompanhar este tópico”. :?

Gostei da sua arquitetura, entretanto estou aguardando outras idéias. :wink:

Fui!

Pois é.Estranho não?!Mas eu não estou querendo arranjar encrenca, e se vierem críticas aceito numa boa.

Mas parece que a galera saturou… :lol:

Vou esperar.

A Paz!!

O Fórum do GUJ está estranho mesmo (deve ser pq é 100% java agora… :wink: )… Qlqr coisa estou por aqui. 8)

Fui!

Daniel_Quirino_Olive

DAO? Olhe isso: http://www.javaworld.com/javaworld/jw-03-2002/jw-0301-dao.html

Daniel_Quirino_Olive

Mas eu não curti muito a idéia do cara. Primeiro, “IUsuarioDAO”? Que maneira de nomeação mais tosca! Segundo e mais importante do que a convenção: para quê criar diversas interfaces para vários DAOs? Crie uma única interface e faça com que todos a implementem. Simples assim.

paulohbmetal

Agora entendi, por que estes tópicos dão encrenca… :slight_smile: Cara calma.

Tudo bem pode até ser, mas se eu precisar de um método mais específico?

A Paz!!

Daniel_Quirino_Olive

Método específico? Tipo o que?

Mas, ah!, fala sério. Aquele tipo de convenção é muito feia! :frowning:

paulohbmetal

Daniel Quirino Oliveira:
Método específico? Tipo o que?

Mas, ah!, fala sério. Aquele tipo de convenção é muito feia! :(

Tipo sei lá buscar as dependência deste usuario, como acesso.Qual convenção vc usa?

A Paz!!

F

Eu tb não curti muito, principalmente onde tu diz que instancia na tua View as regras de negocio. Se tu quer usar MVC ta faltando coisa nessa arquitetura.
Outro ponto, framework nenhum? Ta fazendo tudo no braco do zero?

paulohbmetal:
Daniel Quirino Oliveira:
Método específico? Tipo o que?

Mas, ah!, fala sério. Aquele tipo de convenção é muito feia! :(

Tipo sei lá buscar as dependência deste usuario, como acesso.Qual convenção vc usa?

A Paz!!

Bom se tu precisar de algo mais especifico ai tu cria uma classe mais especifica, faca isso quando necessário agora nao faça como você fez só pq acha que vai precisar de algo especifico mais pra frente.

]['s

paulohbmetal

Mas onde eu iria instanciar?Como minha GUI teria acesso a classe de negócios?

Não, estou fazendo em JDBC puro.Talvez possa usar Hibernate mais pra frente.

Quando digo view, quero dizer GUI.Não quer dizer que estou usando o MVC.
Mas tudo bem, agora só estou esperando exemplos, pois até o momento só li críticas e ninguém me mostrou como “é” o correto.

Vamos lá galera postem códigos pois tenho certeza que muita gente vai aprender/tirar dúvidas com esse tópico, inclusive eu. :wink:

A Paz!!

caiofilipini

Mas deveria. E não porque MVC é bonito. É porque, se bem implementado, funciona. :wink:

No seu caso, parece que tá faltando separar melhor as coisas, implementar alguém (controller) que intermedie as chamadas da sua view para os seus objetos de negócio. Se isso não for feito, você estará amarrando demais a sua view com os objetos de negócio, e isso pode te dar dor de cabeça, principalmente quando você precisar mudar qualquer coisa na camada de negócio.

[]'s

paulohbmetal

Vc tem algum exemplo de controller fazendo isso?Seria implementado por um facade?

A Paz!!

caiofilipini

Não exatamente.

Não tenho nenhum exemplo de controller pra aplicações desktop. Mas você pode dar uma olhada no Pendulum, que é uma implementação de MVC pra desktop baseada no XWork e no PicoContainer.

[]'s

pcalcado

O Controlador é quem recebe toda e qualquer solicitação da visualização e repassa para o lugar correto.

Falando assim, pode pareceruma super-classe faz-tudo, mas não, o controlador apenas repassa a solicitação para outro trabalhador, é o nosso famoso ‘despachante’, tão comum em repartições públicas brasileiras :lol:

[]s

paulohbmetal

Não exatamente.

Não tenho nenhum exemplo de controller pra aplicações desktop. Mas você pode dar uma olhada no Pendulum, que é uma implementação de MVC pra desktop baseada no XWork e no PicoContainer.

[]'s

Não, acho que vou ficar com o DAO mesmo…

Agora gostaria de ídéias para nomenclatura, já que está parecendo tão “tosca”…

A Paz!!

paulohbmetal

pcalcado:
O Controlador é quem recebe toda e qualquer solicitação da visualização e repassa para o lugar correto.

Falando assim, pode pareceruma super-classe faz-tudo, mas não, o controlador apenas repassa a solicitação para outro trabalhador, é o nosso famoso ‘despachante’, tão comum em repartições públicas brasileiras :lol:

[]s

Mas se ele somente “repassa”, qual seria a real vantagem de usá-lo?:roll:

A Paz!!

caiofilipini

Veja bem, DAO é uma coisa, Controller é outra completamente diferente!

Tem certeza que você leu as minhas respostas? Eu falei sobre isso na minha primeira:

[]'s

pcalcado

paulohbmetal:

Mas se ele somente “repassa”, qual seria a real vantagem de usá-lo?:roll:

Porque você não espalharia suas classes de negócio (sejam interfaces para elas, façades…) pela sua apresentação.

[]s

paulohbmetal

Putz que confusão…:lol:
Eu sei…Estou falando entre MVC e DAO.

Agora sobre o “repassa”, eu estou respondendo o pcalcado.

A Paz!!

paulohbmetal

Eu falo em real vantagem, pois se for para não acoplar a Apresentação à Regra de Negócio, esta classe intermediária não estaria fazendo isso?Ou tem mais “outra coisa” que ela pode fazer antes de passar para a classe de Regra de Negócio?

A Paz!!

paulohbmetal

pcalcado:
paulohbmetal:

Mas se ele somente “repassa”, qual seria a real vantagem de usá-lo?:roll:

Porque você não espalharia suas classes de negócio (sejam interfaces para elas, façades…) pela sua apresentação.

[]s

Hum…Então quer dizer, por exemplo, se tenho que fazer acesso a duas classes de Regra de Negócio diferentes em minha GUI, eu o faria através desta classe intermediária?É isso?

A Paz!!

pcalcado

Putz que confusão…:lol:
Eu sei…Estou falando entre MVC e DAO.

Ele quis dizer q vc pode usar DAo e MVC trsanquilamente no mesmo sistema (deveria, aliás) e que xWork, blablabla não interfere no uso de DAO ou não. :wink:

Qual classe intermediária?

Considere por exemplo a estrutura de servlets. Um formulário HTML não realiza ações (ok, num mundo perfeito…), ele as passa para servlets.

Considerando que implementar um Servlet para cada ação a ser realizada é uma prática muito ruim pela compelxidade e blablabla, você implementa o padrão Command para realizar sua ação (ok, você poderia ter MVC com servlets puros, mas vamos esquecer isso por agora).

Usando o padrão Command, você teria um objeto por ação executada (sem if(isso) faz aquilo, pelo amor de Zahl!), e o seu Command aciona as classes encessárias para efetuar sua ação.

A vantagem é que sua classe de visualização, seu formulário, sua página web, sei lá, não precisa saber qual a classe que faz a ação dela. Num modelo em HTTP, ela apenas precisa saber que para inserir um usuário ela deve passar seus parâmetros para o controlador (que, enste caso, é um servlet) passando a chave 'incluirUsuario.do (exemplo Struts, péssima prática, aliás :P). O controlador sabe que esta chave indica para usar o objeto Command, por exemplo, IncluirUsuario (poderia ser um método de um objeto de granulação grossa, mas vamos manter simples), passar os parâmetros e mandar ele se virar.

Sua classe de visualização fica muito mais limpa e muito menos acoplada.

[]s

paulohbmetal

:?: :? :?:

pcalcado:
A vantagem é que sua classe de visualização, seu formulário, sua página web, sei lá, não precisa saber qual a classe que faz a ação dela. Num modelo em HTTP, ela apenas precisa saber que para inserir um usuário ela deve passar seus parâmetros para o controlador (que, enste caso, é um servlet) passando a chave 'incluirUsuario.do (exemplo Struts, péssima prática, aliás :P). O controlador sabe que esta chave indica para usar o objeto Command, por exemplo, IncluirUsuario (poderia ser um método de um objeto de granulação grossa, mas vamos manter simples), passar os parâmetros e mandar ele se virar.

Ô lôco… :shock: Que volta!!

Então vamos ver se eu entendi, eu teria um controlador para toda a minha aplicação e essa aplicação delegaria ao comand o que ele deve fazer passando os parâmetros nescessários e o comand delegaria a minha Regra de Negócios?Ou eu estou misturando tudo?:oops:

O problema é que não desenvolvo pra Web, e ás vezes fico meio perdido…

A Paz!!

F

Paulo,

Não querendo ser chato, pelo modelo que tu implementou vou quebrar teu sistema ok? Vamos pensar um pouco.
Sou o usuario que te contratou para fazer o sistema. Ai no dia da apresentacao do mesmo eu olho e digo, ué mas eu pensava que ia ser na Web o sistema. Nesse momento tu faria uma cara ± assim :shock: .

Agora pensa o problemao que tu teria que resolver deixando como esta, não acha?
Pesando mais um pouco, se tivesse usando MVC qual seria teu problema realmente? Trocar a View nao é?

Voltando as dicas, eu procuro usar o pattern Observer na minha view para notificar as alteracoes.

paulohbmetal

É vc tem razão, mas descobrir isso no dia da apresentação seria meu primeiro grande erro.

Mas estava dando uma estudada, e achei entre uns tutoriais que tenho impressos lá em casa, esse
da Sun que fala sobre DAO.

O que acham?

Achei meio estranho o fato de uma classe ter acesso a todos os DAO’S.Pro meu caso, é lógico.Vcs fazem assim, deixam tudo public?

A Paz!!

F

Não pense isso, é normal o cara chegar com o sistema em baixo do braco e o cliente dizer que não era bem aquilo.

]['s

pcalcado

Ok, isso acontece, mas uma mudança tão drástica assim deveria ser prevista pelo programador, mesmo porque o cliente deveria ter visto uma prévia do sistema antes de ser entregue.

Mesmo assim, o modelo MVC oferece muito mais vantagens do que simplesmente facilidade em trocar de interface, mesmo porque esta facilidade depende bem mais de uma boa arquitetura de camadas do que o MVC em si, visto que dependendo de como se use MVC pode ficar mais acoplado do que views acessando objetos de negócio, não duvidem…

[]s

paulohbmetal

Por isso mesmo que falo…Onde está a análise?!
É posso reconsiderar e usar o MVC mesmo…

Estava também olhando EJB e me parece uma boa, mas entro na velha história do “escrever mais”…Dá-lhes Deployment Descriptors…

O que acham?!

A Paz!!

pcalcado

Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer… seja lá que bizarrice inventarem…

Dá pra evitar muito do trabalho com xdoclet, mas, sinceramente, não vale a pena. Fique onde está…

[]s

paulohbmetal

pcalcado:

Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer… seja lá que bizarrice inventarem…

Tudo bem, mas vc desenvolver uma aplicação em Swing e no dia de apresentar vc decobrir que era pra Web é demais né?!:wink:

Pois é, e o EJB 3.0?!Vcs acham que resolve o problema?!

A promessa é essa né?!..

A Paz!!

Daniel_Quirino_Olive

O problema de análise seguindo os meios tradicionais é que você perde muito tempo desenvolvendo algo que não agrega nenhum valor ao seu projeto e que pode ser jogado no lixo a qualquer mudança de humor do seu cliente.

Então, cuidado antes de abrir sua ferramentinha CASE e sair desenhando alucinadamente o sistema inteiro, usando 8 diagramas da UML e o diabo.

Sobre EJB 3.0, o mecanismo de persistência ainda é mais promessa do que realidade. Ainda me pergunto se, quando a especificação for lançanda, eu vou adotá-la ou permanecer ao lado do Hibernate para persistência :stuck_out_tongue:

Aliás, uma boa visão sobre este assunto é a do Tirsén: http://blogs.codehaus.org/people/tirsen/archives/000706_why_i_still_wont_do_ejb.html

F

paulohbmetal:
pcalcado:

Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer… seja lá que bizarrice inventarem…

Tudo bem, mas vc desenvolver uma aplicação em Swing e no dia de apresentar vc decobrir que era pra Web é demais né?!:wink:

Claro que é demais, foi apenar um exemplo bobo, para ver alguns problemas que podem aparecer. Como o Philip falou mesmo com MVC teu sistema pode ficar estremamante acoplado e isso não é bom. Por isso trabalhar com padrão de projetos é o ideal, IoC, Observer, e por ai vai é importante.

Sobre analise, eu prefiro a visão do XP, não pense que a analise te afasta de todos os males, pois o mais comum é definir coisa demais que na realizadade o cliente não precisa. É aquela famosa figura do balanco.

]['s

F

E se tu usar Hibernate3 estara usando EJB 3.0, correto? :stuck_out_tongue:
Segundo o Gavin na entrevista ao JF o Hib3 sera uma implementação da especificação do EJB 3.0 a qual ele é um dos menbros.

]['s

gcobr

Alguns comentários:

Se você optar por uma arquitetura em 3 camadas (cliente swing, app server e DB) dificilmente conseguirá implementar um MVC que ligue a View (swing) ao Model (domínio de objetos no app server). Pelo menos não de uma forma muito produtiva.

Há cerca de um ano estou trabalhando em um sistema de grande porte que utiliza uma arquitetura assim. Levamos cerca de 6 meses só para defini-la: quais frameworks seriam usados, que EJB faria o que, como resolveriamos a persistência, etc.

O mais provável é que você implemente MVC na interface para apresentar dados dos seus objetos de domínio em formulários Swing.

Me parece também que existe uma série de questões complicadas que ainda não foram ponderadas para este caso:

  • A serialização e transporte de objetos do app server para o cliente e vice versa pode se tornar um grande problema. Quanto maior o número de relações entre os objetos pior será. Para resolver isso, terá que implementar proxies e possivelmente trabalhar com uma estrutura paralela de DTOs (Data Transport Objects). Escrevendo cada vez mais e mais código.

  • Certamente serão necessárias validações da entrada de dados no lado cliente. Os controles do swing (JTextFields, etc) provavelmente terão que ser estendidos para isso, ou você terá que criar Documents e outros modelos para eles.

  • Frameworks para desenvolver UI Swing são escassos e menos populares do que os que você encontra para Web. Prepare-se para escrever muito código!

Desenvolver interface em Swing é geralmente muito menos produtivo do que desenvolver interface Web. Você morre nos detalhes!
Ao apresentar a aplicação para o cliente ele esperará encontrar na interface uma riqueza de detalhes e facilidades de uso e interação que qualquer programador Delphi ou VB consegue fazer com meia dúzia de clicks, mas que vão te custar a alma para desenvolver em Swing.

Dependendo dos requisitos pode ser muito mais fácil usar XUL, com Thinlet ou outro qualquer.

Gabriel.

pcalcado

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.

[]s

gcobr

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.

pcalcado

Sim, arquitetura de Objetos distribuidos em camadas.

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.

Dependendo do nível de distribuição e complexidade, você irá usar objetos DTO para passar dados agrupados, isso é uma limitação terrível de arquiteturas distribuídas, mas não é impossível de lidar.

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.

Se estamos falando de componentes distribuídos, aconselho uma leitura sobre o tema. Objetos internos à componentes não devem passear pelo sistema.

Em telecomunicações, geralemnte você possui mais de 3 tipos de interface para um sistema. A lógica de negócios é uma, o que varia é a interface.

Um modelo MVC utiliza as mesmas interfaces de negócio que um protocolo binário de tempo real. Para o modelo MVC, apenas estas interfaces são o modelo, para os outros clientes geralmente é um subsistema a ser acessado.

gcobr:

Codificar isso em um formulário já é bastante trabalhoso e codificar algo mais entre as camadas me parece ainda mais.

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.

Luca

Olá

MVC do jeito que vc fala no Java só existe no Swing e mesmo assim parcialmente. O modelo dos frameworks web (mesmo JSF) V-C-M e V não deve dialogar diretamente com M.

OK, vide obs. acima

Nem sempre é preciso serializar os objetos. Concordo que é bem prático em termos de programação mas se o objetivo for performance é melhor dedicar um pouco mais de tempo no desenvolvimento e facilitar o uso na produção.

Certo, tudo deve ser componentizado, padronizado, pasteurizado, flavorizado, customizado, colorizado e dará muito trabalho.

O cliente resolveu usar Linux e nós já estamos prontos para tal. Vide Droga Raia, Banco Postal, etc.

[]s
Luca

gcobr

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.

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.

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

Se for assim, use VB. Um programador VB faz um sistema gigantesco em duas horas… ah, é claro, ele não consegue dar manutenção nele.

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.

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).

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?

Prever possíveis alterações futuras é um dos maiores erros que um designer pode cometer no mundo de hoje. Aumenta a complexidade desnecessariamente de um sistema, e na maioria dos casos o sistema não segue a previsão.

Desculpe, mas isso aí foi nada com coisa nenhuma.

Produtividade e Design? linahs gerais? O que você quis dizer com isso?

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.

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!

J2EE, MVC, etc. são utilizados em sistemas de todos os tamanhos, incluindo sistemas com espoco muito maior e mais crítico do que você citou.

gcobr:
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.

Mesmo hoje existem sistemas (e muitos) em que COBOL é verdade.

gcobr:

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.

Mas não há qualquer motivo para seu formulário processar regra de negócio.

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.

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.

Arquiteturas de três camadas não necessariamente envolvem sistemas com requistios enormes, mas ainda que envolvam um cliente usando modelo MVC pode ser tão útil (ou inútil) quanto qualquer outro.

gcobr

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.

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.

Me refiro a produtividade na realização das adaptações. Essa é a relação.

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.

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.

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.

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?

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.

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.

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.

Luca

Olá

Complementando minha resposta anterior com um exemplo de aplicação web de várias camadas usando V-C-M com interface de usuário swing.

Mais uma vez vou citar o Banco Postal.

:arrow: 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.
:arrow: Controller - servlet que intermedeia as transações traduzindo para o formato ou protocolo adequado à camada adjacente.
:arrow: 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.

[]s
Luca

gcobr

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.

gcobr

Luca:
Mais uma vez vou citar o Banco Postal.

:arrow: 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.
:arrow: Controller - servlet que intermedeia as transações traduzindo para o formato ou protocolo adequado à camada adjacente.
:arrow: 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.

pcalcado

Um ‘design produtivo’? É difícil avaliar o quanto um design é produtivo em mudanças numa implementação quando você não sabe o que vai acontecer. A ‘produtividade’ cai por terra.

Isso é complicado. Você vai replicar o domínio na apresentação, muitas vezes desnecessariamente. Sem generalizações, não é possível sugerir uma bomba dessas para todos.

Então porque você colocou isso numa discussão soobre MVC?

Não, estou dizendo que produtividade é uma métrica relativa, marketeira e incomparável. E se o cliente quiser COBOL, quem sou eu para reclamar?

E qual a limitação de MVC quanto a isso?

O foco da discussão é o M. MVC divulga uma ótima prática que é separar lógica de apresentação do diálogo de usuário, mas isso não é feito só em MVC. Não é porque você não usa MVC que você não tem Model.

O sistema que você descreveu também acessa seu domínio, também vai precisar de transfer objects se necessário… não existe motivo para dizer que MVC é pouco produtivo porque você vait er que usar uma ou otura coisa que você vai acabar usando mesmo fora de um modelo MVC.

Não existe bala de prata, e MVC pode acrescentar complexidade desnecessária à mutias aplicações, mas quando sua interface cresce, é sempre interessante seu uso.

Luca

Olá

Não sei do seu caso, mas no Banco Postal há no máximo umas cento e poucas transações. Como foi tudo componentizado, o trabalho não foi tão grande assim. Tudo sempre era feito de modo genérico dentro da cadeia de responsabilidades. Em apenas 6 meses se partiu do zero e se colocou em produção.

Trabalhei em uma outra aplicação muito mais simples (captura de cartão de crédito) em que as transações trafegavam como objetos serializados por http/https. Coloquei http em negrito porque isto para mim é o mais importante pois http passa em qualquer firewall. O fato dos objetos estarem serializados simplificou muito o desenvolvimento, principalmente do servidor que funcionava como Controller. Como tudo era genérico era assustador o tamanho minúsculo dele. Por reflection se obtia tudo. Mas no Banco Postal havia o requisito de 200 tps e aí se decidiu codificar mais para não sacrificar o throughput.

[]s
Luca

paulohbmetal

Ô galera, dei uma sumida pois estava praticamente off line…

Bom, já vi que existem várias opniões sobre o caso.Mas eu gostaria de saber uma outra coisa:Como vcs fazem o controle de transação?!

O problema é que minhas classes de regra de negócio podem fazer uso de outras classes de regra de negócio, daí não posso ficar colocando commit em todos os métodos dos DAO’s.

E aí?! :roll:

A Paz!!

pcalcado

Paulo,

Não pense em transações como restritas ao banco de dados, pense nelas em sistema como um todo.

Dê uma lida em artigos de JTA.

[]s

B

Utilizando OO vc elimina a situação de vc poder vir a ter alguma ação específica.

Ex: Vc tem a classe a interface Generic com os métodos A, B e C e a classe UsuarioDAO que implementa Generic. Vc precisa do método XYZ, que será específico para UsuarioDAO? Então crie um classe UsuarioEspecifica (ou qualquer outro nome) que extende UsuarioDAO. A partir daí vc passa a chamar UsuarioEspecifica e não mais UsuarioDAO, eleminando o seu problema.

Acho que é isso.

Abraço.

Criado 10 de novembro de 2004
Ultima resposta 10 de jun. de 2005
Respostas 50
Participantes 9