JSF + Interface

Programação Java
#1

Pessoal estou com um problema, digamos que não de funcionalidade e sim de conceito de encapsulamento.

Tenho 1 classe ModelProfile

public class ModelProfile

private String username{

    public String cadastraProfile(String username)
   {
       this.username = username;
   }
}

Tenho uma interface AcessoProfile

public interface AcessoProfile{

    void cadastrarProfile (String username)
}

1 classe controller ControladorProfile

public class ControladorProfile extends ModelProfile implements AcessoProfile {

    private String username;

    @Override
    public void cadastrarProfile (String username)
    {
  
    }

    public void cadastraProfile()
    {
         cadastrarProfile (username);
    }

    get username;
    set username;
}

E 1 página JSF que via passar esses dados e é ai que entra o problema.

Quando eu dou o seguinte comando:

<h:commandButton value="Cadastrar" action="#{controladorProfile.cadastraProfile}"/>

Bem no objeto controladorProfile, é exibido não somente os métodos da classe controlador, mas também da classe ModelProfile, o quel seria o motivo de eu estar usando uma interface, para agentes externos não terem acesso as classes internas do sistema.

Como em JSF eu não consigo implementar diretamente uma interface, tive que passar as variaveis para a classse controladora e ai acionar uma função que vai acionar a interface.

O que acham?

#2

Cara,

Não vejo sentido o teu controlador herdar sua classe de modelo. Seria bem melhor se você instanciasse sua classe de modelo no teu controlador.

Também não entendi o uso da interface nesse caso. O ideal, na minha visão, seria o teu controlador não escrever métodos de persistência nem de negócio. Para isso, na minha opinião, você poderia criar uma classe de serviço que implementaria a sua interface, e no teu controlador você chamaria essa interface e usaria os métodos dela.

#3

Silver00,

Concordo com o edubis.

Em OO o lema é “alta coesão e baixo acoplamento”. Nesta sua arquiterura vc está fazendo o contrario.
Vc está fazendo com que eu Bean “SEJA” um Model e não que “TENHA” um model.

Eu faria o Bean ter um model e o model invocaria um serviço responsável pela persistência. (como o edubis comentou)

#4

[quote=edubiss]Cara,

Não vejo sentido o teu controlador herdar sua classe de modelo. Seria bem melhor se você instanciasse sua classe de modelo no teu controlador.

Também não entendi o uso da interface nesse caso. O ideal, na minha visão, seria o teu controlador não escrever métodos de persistência nem de negócio. Para isso, na minha opinião, você poderia criar uma classe de serviço que implementaria a sua interface, e no teu controlador você chamaria essa interface e usaria os métodos dela.[/quote]

edubis,

Entendi, então ficará na seguinte estrutura: JSP -> Controlador -> ClasseServiço -> Interface -> Bean?

Sobre a classe controladora herdar de model é que acabei fazendo confusão, e por fim, não sabendo como encaminhar a solicitação da interface para a classe model, que lá acionarei algum método de persistencia da minha classe DAO (o qual omiti no exemplo acima).

Só que tem um porém, no JSF eu não consigo chamar uma função passano os parametros que eu capturar, eu tenho que jogar em algum modelo de persistencia. Pelo menos eu não achei nenhum exemplo que faça igual ao HTML, no qual eu consigo capturar os dados em variaveis e passa-los chamando os metodos das classes.

[quote]Silver00,

Concordo com o edubis.

Em OO o lema é “alta coesão e baixo acoplamento”. Nesta sua arquiterura vc está fazendo o contrario.
Vc está fazendo com que eu Bean “SEJA” um Model e não que “TENHA” um model.

Eu faria o Bean ter um model e o model invocaria um serviço responsável pela persistência. (como o edubis comentou)[/quote]

hmsilva,

É que para as operações de persistencia, geralmente eu uso uma classe DAO que eu não coloquei no modelo que dei de exemplo, aquele model esta apenas fazendo a operação de manter os dados que irei pegar na minha classe DAO.

#5

silver00,

Uma arquitetura básica que uso e gosto é JSP -> Controlador -> Interface -> Serviço/DAO -> Modelo.

Um exemplo básico de uso, usando o exemplo que você colocou no início seria:

  • (Modelo) Classe de modelo com seus atributos e getters e setters.
  • (Serviço/DAO) Classes de persistência e regras de negócio.
  • (Interface) Abstrai os métodos dos serviços e DAOs.
  • (Controlador) Cuida das regras de tela somente.

Não sei se entendi, mas tu podes instanciar o teu model no controlador, popular ele com os dados, e depois passar esse model pra persistência. Exemplo:

<h:inputText value="#{controladorProfile.profileModel.userName}"/>
<h:commandButton value="Cadastrar" action="#{controladorProfile.cadastraProfile}"/> 
public class ControladorProfile  {  
  
    private ProfileModel profileModel;
    private ProfileService profileService;  
  
    public void cadastraProfile()  {  
         profileService.cadastrarProfile(profileModel);
    }  
  
    //getters  
    //setters
}

Algo nesse sentido.

#6