Na minha opinião ficaria em uma classe separada, digamos ValidationUtils.
E ou o modelo ou o controller chamariam esse método na hora de validar o Cliente, dependendo da abordagem, mas eu provavelmente colocaria no controller um método validarCliente, e dentro desse método chamaria o validaCPF
:?: 2ª Pergunta: Quem é o responsável pela restrição na entrada de dados no View? Por exemplo, onde ficaria o método que validará se determinado campo “X” da View realmente só tem conteúdo numérico? Modelo, Visão ou Controle?
Sobre a primeira pergunta: Na minha opinião eu colocaria a validação de cpf na regra de negócios (acredito que seja teu UsuarioModel) e também na apresentação (UsuarioView). Claro que você também pode colocar em uma classe ValidationUtils, conforme o colega acima citou. Outra forma poderia ser uma classe Cpf, com um método que verifica se o valor contido no objeto é válido. Parece uma forma bacana porque é ‘mais’ orientada a objetos.
Sobre a segunda pergunta: Na minha opinião é responsabilidade do controller fazer o trabalho de binding de dados entre a view e o model.
:?: Se eu criar a classe CPF, quem vai criar o objeto dela na hora que eu clicar no JButton “Cadastrar Usuario” que está na View? O Controle? Ou ele somente vai passar para o dado para o Bean (Model)?
:?: Se o UsuarioModel.java (Model) for um Bean, então o atributo para cpf e seus get/set serão um objeto CPF no lugar de long, int?
:?: Ou seja, no controle do botão existirá métodos de verificação dos dados mandados pela GUI (View) antes de passar ao seu Bean (Model)?
Na minha opinião, o controller deve fazer isso. Obter o dado (long, String, etc) e converter para o tipo Cpf.
Sim.
Na minha opinião, o controle do botão (você quer dizer o evento?) faz parte da view, ou seja, não seria o lugar adequado. Eu colocaria no controller. Que nos casos dos frameworks web é utilizado o padrão front controller.
Vejo que você está implementando o MVC para um aplicativo desktop. Talvez seja legal você ver algumas implementações existentes, só para pegar algumas idéias. Em uma busca rápida eu encontrei alguns resultados que podem ser úteis:
:?: 3ª Pergunta: Quem vai instanciar uma classe DAO? Modelo, Visão ou Controle?
Está correto dizer que devo criar métodos no Bean do tipo Cadastrar, Alterar, Excluir e Consultar que usem um objeto DAO? Ou seja, é correto instanciar uma DAO no Bean?
Algumas perguntas tuas estão além do MVC. MVC por si só não diz onde fazer acesso a base de dados por exemplo. Nem fala que entidades não deveriam manter referências a DAOs. Você precisa se basear em uma arquitetura e pensar a respeito dela. O papel do MVC é outro e além disso cada caso é um caso.
Agora, instanciar DAOs em controller não parece ser boa idéia. Os controllers estão agindo como intermediários entre o model e a view e não vejo sentido o uso de DAOs nessa comunicação.
Entendo como modelo o local onde estão as regras de negócio (os dados e as formas de modificá-los).
:?: A princípio eu entendo que o correto seria a DAO ser chamada pelos métodos do modelo. Se for pegar como exemplo as classes do primeiro post que é um cadastro de usuário, entendo que quando fosse necessário usar o bd a classe UsuarioDAO.java seria acionada a partir de métodos da classe UsuarioModel.java. Mas pesquisando, muita gente diz que uma DAO pertence ao model também. Aí fica minha dúvida: DAO é também um modelo?