Estamos discutindo a refatoração de uma aplicação! Nossa aplicação tenta seguir o padrão MVC, porém, estamos com dúvidas referente a separação entre a view e o controller a partir de interfaces.
Se o objetivo do MVC e separa model e view, pq separar e ter tanto trabalho para separar o controlador? Isso criaria a quarta camada, não? E depois a quinta e sexta e …
Acredito que essa não seja uma boa solução, visto que teremos inúmeras interfaces e que a manutenção será dobrada por conta visto que a interface da view deverá ter a assinatura de todos os métodos para poder ser manipulados no controller e vice versa.
Isso geraria na minha opnião mais dependência do que o ter uma view para cada controlador e pronto!
Poderiam dar uma clareada nessas questões?
o código que está para ser aplicado é este:
public interface TesteController(){
public String teste();
}
public interface TesteView(){
public String viewTeste();
}
public class Teste extends JDialog implements TesteView(){
private TesteController; //isso aqui representaria o meu controlador
//codigos iniciais e talls
public String viewTeste(){
//faz algo aqui
}
//codigos extras
}
}
public class Controlador implements TesteController(){
private TesteView; //representaria a minha view
//codigos iniciais e talls
public String Teste(){
//faz algo aqui
}
//codigos extras
}
}
Qual solução aplicar : “Uma View tem um controlador e pronto” ou uma view tem uma interface que representa um controlador e um controlador tem uma interface que representa uma view"
Qual a avaliação de vocês quanto a isso? Preciso de idéias!
Isso não é MVC e MVC não depende da quantidade de camadas. O controlador deve apenas responder pedidos de eventos da view, tratar e atualizar o modelo. Quem atualiza a view é o modelo, que deve estar num estado “bindado” a view. Aconselharia a utilizar um framework de “bind” de bean com a view. Como o Gênesis por ex. Mas ok, vamos lá: Você realmente vai fazer assim? (eu faria o controlador sendo uma classe aninhada, assim não precisaria ter uma referencia a view também no controller). Então está usando interfaces, pq seu nível de abstração entende que um dia pode querer usar IoC para mudar a implementação do controle ? Tudo bem, daria pra fazer assim mesmo.
peerless, A view manda uma info para o controlador, o controlador chama o modelo, carrega as coisas e devolve pra view! certo?
imagine que eu tenha uma JTable, ai quando eu clico em carregar, o controlador chama o modelo para carregar as informaçoes e depois pega uma referencia da view(anônima) para pintar as colunas de vermelho por exemplo caso o valor da coluna numero 1 seja maior que 50.
Uma famila de controladores tbm poderia ser uma boa solução. Na minha opnião! Facilitando o polimorfismo dentro das views!
eu penso comigo que a implementação poderia seria mais flexivel e menos trabalhosa assim:
public class controlador(){}
public class Tela extends JDialog{
private Controlador control;
public Tela(){
control = new Controlador(); // possiveis parametros ignorados
}
}
preciso de avaliações sobre essas soluções, para que eu possa compreender realmente qual a melhor solução…
só um adendo : Interfaces não são Classes, muito menos são Classes Anónimas. Elas podem ser usadas para criar classes anónimas, mas são coisas diferentes.
Criar classe anónima de uma itnerface
Comparator c = new Comparator (){
public int compare(Object a, Object b ){
/// compara
}
}
O Swing já implementa MVC. Então o que vc precisa implementar é MVP (Model View Presenter)
O view são os controles swing. o Presenter são os modelos dos objetos swing (TableModel, etc…)
O swing chama os modelos swing para obter os dados, o modelo swing tem que obter os dados conforme uma logica da aplicação e apresentá-los conforme ( quiçá pintar linhas etc… ) Isso é o Presenter. Uma classe que implementa o modelo swing e mais alguma coisa que seja necessária ( por exemplo um Renderer). Ou divide isso em várias classes e o conjunto será o presenter. O Model é sempre a mesma coisa, o backoffice acessivel via um serviço ou um façade.
sim sim, entendi sim! Mas eu gostaria que generalizasse um pouco mais o nosso contexto! Gostaria de saber sobre as soluções que mostrei! Quais os pontos fracos dessa abordagem com interfaces e se ela é uma boa solução.
Tem muita coisa que eu devo mudar, mas o primeiro passo é o de como melhorar a arquitetura geral de controle (no primeiro post).
