Na camada controle chamar o JOptionPane é feio?

Não é só feio, como é errado também:

a) Você está atrelando a camada de controle ao Swing;

b) Você está deixando o primeiro atributo do JOptionPane como null. Esse atributo tem uma utilidade, e deve ser fornecido o JDialog ou JFrame que o JOptionPane está;

c) Você está obrigando a view a ter um JOptionPane como saída de erro. As vezes, um label em vermelho poderia ser mais adequado.

Organização pode dar um pouco mais de trabalho, o que é normal.

qual a melhor solução neste caso então?? quando tenho JoptionsPanes e camadas separadas: View e Controler?

Se vc exibir uma joptionpane no controle… vc esta quebrando seu mvc… seu padrão ja era…
na visão faz uma instancia de seu controle… e na visão vc exibe a mensagem…

A solução é a camada de controle ter métodos para a verificação. Ou disparar uma exceção, que será exibida na view de alguma forma.

Eu sobrescrevo o que o Viny falou. Não apenas é feito, é errado.

Design é dificil , Bom design é trabalhoso, mas é isso que diferencia um bom desenvolvedor de um montador de codigo.
Escrever codigo é fácil, fazer bom design é dificil.

A ideia é separação de responsabilidade pelo encapsulamento. A melhor forma de desenhar encapsulamento é pensar (eu disse pensar) “E se eu trocar swing por outra coisa?” Se o controlador da aplicação depende do swing , já era.

é muito simples isolar. Vc cria uma interface UserActiveMessanger esta classe é responsável por pergunta coisa ao usuário e mostrar mensagens de fluxo (como exeções ou falhas nas regras de negocio) as interface é simples e não depende do swing, por exemplo

public interface UserActiveMessanger   {
public void mostraAviso(String texto); // ok com um texto
public boolean confirma(String texto); // sim ou não
public int decideContinuar(String texto) ; // sim, não, cancelar
}

Depois é só implementar usando swing. O controlador recebe um objeto do tipo UserActiveMessanger e nem lhe interessa como isso aparece para o usuário . O usuario poderia ser um ET usando telepatia, tanto lhe faz.

Isto é chamado Inversão de Controle porque quem controla a acção é o UserActiveMessanger e não o controlador de aplicação. O controlador de aplicação invoca o quê ele quer fazer mas não o como. Esta e uma forma simples de resolver a maior parte das dependencias tecnologias e isolar objetos de outros objetos em outras camadas ou APIs.

Realmente esta errado, vou refazer o codigo :D, valeu pessoal,

abs p todos

entendi esse controle como funciona…

minha única dúvida eh a seguinte:

hoje tenho:

Controles

e

Formulários

Um Controle tem um Formulário e um Formulário tem um Controle. (sei que não eh a melhor forma… mas como ficaria então??)

O Controle teria um atributo UserActiveMessanger pra referenciar quem eh a visão??

e a visão Implementaria essa interface UserActiveMessanger??