Arquitetura de software - modelagem de camadas

Programação Arquitetura
#1

Pessoal eu sei que tem muitos tópicos que abordam esse assunto, porem venho tendo alguma dúvidas em relações a isto, outra coisa eu sei que cada situação é algo diferente, mais sempre temos um meio termo comum entre todos, minha ideia aqui é analisar um certo e um errado sobre ha analise de camadas de software.

Vamos la

programa cadastra pessoa

1-) Persistencia
- PessoaDAO (DAO)
- Pessoa (Entidade)(seria o Modelo do MVC?)

2-) Logica Negocio
- PessoaBO (Objeto de negocio - temos o metodos de negocio da pessoa)(seria o Modelo do MVC?)

  • PessoaFacade( aqui fica as validações, logo que eu migrar de jsf para flex ou outra coisa, não preciso criar novamente, porem eu não sei em que camada se encaixa)

3-) Apresentação
-MBPessoa(controle)
-pessoa.xhtml(visão)

Ou

1-) Persistencia
- PessoaDAO (DAO)

2-) Logica Negocio
- Pessoa (Entidade e objeto de negocio com os metodos)(seria o Modelo do MVC?)

  • PessoaFacade( aqui fica as validações, logo que eu migrar de jsf para flex ou outra coisa, não preciso criar novamente, porem eu não sei em que camada se encaixa)

3-) Apresentação
-MBPessoa(controle)
-pessoa.xhtml(visão)

Deste já agradeço

#2

Depende de muita coisa.

inclusive da abordagem que você está seguindo, (DDD, GRASP, etc.)

dá uma olhada neste blog, pode te ajudar.

#3

Interresante, mais alguem poderia opinar?

#4

Um Managed Bean pode desempenhar papel de Model, View ou Controller. Aliás, pode ser uma boa prática separar essas responsabilidades entre seus managed beans, de forma que cada um desempenhe um papel bem definido.

Managed Beans que auxiliam o comportamento da UI são componentes View.
Model Beans contém dados que são apresentados para ou enviados pelo usuário e garantem a integridade desses dados.
Controller Beans recebem as requisições do FacesServlet e interagem com View beans e Model Beans. Gerenciam o fluxo de navegação.

O que acontece no JSF é que, como essa separação não é forçada, nem explícita, é muito fácil jogar todas as responsabilidades em um único Bean e depois ficar se perguntando onde diabos está o tal do MVC…

#5

esmiralha vamos la

Model = "contém dados que são apresentados para ou enviados pelo usuário e garantem a integridade desses dados. "

no caso uma entidade ou DTO certo?

Controller “recebem as requisições do FacesServlet e interagem com View beans e Model Beans. Gerenciam o fluxo de navegação.”

no caso um MB certo? se eu tiver a entidade ou o DTO nele ele vai receber a requisições do Faces e pupular o (DTO ou Entidade) ele vai fazer este controle

view xhtml certo?

#6

Erick,

Você pode particionar as responsabilidades de MVC entre seus Managed Beans de forma mais granular do que simplesmente Entidade-MB-XHTML. Essa distribuição leva geralmente a um acúmulo de responsabilidades por parte do MB.

A idéia é que você tenha managed beans mais especializados.

Um Model Bean adapta o Domínio à camada de Apresentação. Por exemplo, você tem uma tabela que mostra nome da disciplina, código da turma, nome do professor, nome do aluno, misturando informações de diversos objetos diferentes. Você pode colocar isso diretamente na View com expressoes do tipo: ${turma.professor.nome} e ${turma.aluno[i].nome}. Isso acopla fortemente a View ao Domínio. Eu prefiro criar um objeto que sirva de Model para atender essa necessidade. Um Managed Bean RelatorioTurmaModel com propriedades que espelham aquilo que o caso de uso precisa. Isso acopla a View a esse Model mas eu sei onde está o acoplamento… Lembre-se que tudo que aparece numa View provém do Domínio mas nem sempre a granularidade é a mesma.

Por outro lado, em GUIs mais complexas existem determinado estados que pertencem única e exclusivamente a uma View específica. Para representar esse estado pode-se usar um View Bean que é intrinsecamente ligado àquela View. Por exemplo, determinar se uma tab está habilitada ou não.

Já as decisões de navegação podem ser deixadas a cargo de um Controller Bean que é também é um managed bean. Ele recebe requisições da View através do FacesServlet, interage com o Domínio, popula o Model e seleciona a proxima View.

[code]public class VeryBusyMB {

//View
private boolean isTabSelected;

//Model
private Turma;

//View
public boolean isTabSelected{
}

//View
public void setTabSelected(boolean isTabSelected) {
}

//Model
public Turma getTurma() {
}

//Model
public void setTurma(Turma turma) {
}

//View
public void toggleTab(ActionEvent evt) {
}

//Controller
public String loadReport() {
this.turma = consultaTurma();
return “report”;
}

}

[/code]

É muito comum os Managed Beans misturarem muitas responsabilidades como acima. Em soluções simples, pode até ser uma boa prática, quem sabe?

Enfim, pense na separação de responsabilidades das suas classes e tome suas decisões de maneira consciente… É difícil, muito difícil mesmo, mas vale a pena…

#7

a abordagem do camarada de cima é legal
vou complementar:

MVC

Modelo -> Pessoa;DAOPessoa
é nessa camada que fica a lógica de negócio, é quando você for fazer o levantamento dos requisitos
é em busca disso que você faz para gerar diagrama de classes

Controle -> ControlePessoa
é normalmente o objeto mais completo, mais complexo do sistema
ele toca o bumbo, é nele que praticamente tudo acontece…

Visão -> TelaPessoa
Nessa camada só pode ter visão
o conceito de visão é uma visão burra…quem sabe o que ela faz é o controle dela

Normalmente o fluxo é…

tela apertou botão -->
controle captura -->
controle chama a dao --> dao busca do banco e joga pro Bean (PESSOA)
controle busca do BEAN e joga pra tela

funciona + ou - assim

abraçao

#8

Erick,

O padrão MVC é um padrão da camada de apresentação implementado transparentemente pelo Framework JSF.

No JSF temos a seguinte disposição de componentes:

ManagedBeans, Converters, Validators --> Modelo
FacesServlet --> Controller
Facelets, Jsp --> Views

O controle de fluxo da aplicação é feito através da interpretação do facesConfig.xml ou via Annotations(JSF2).

O Comportamento da Interface/Aplicação é implementado pelos seus ManagedBeans.

#9

esmiralha o jeito que vc citou acima é o que todo mundo faz né?pois a turma é um dominio que é o Model

como que seria os MB especializados que você fala?

PedroTOliveira

ManagedBeans, Converters, Validators --> Modelo
FacesServlet --> Controller
Facelets, Jsp --> Views

conheci uma pessoa que falava exatamente isto porem nunca intendi porque o modelo seria (ManagedBeans, Converters, Validators) e não o dominio porque?
FacesServlet --> Controller e porque não MB sempre eu soube que o controle era MB pois ele controla o acesso da viw e o modelo (no caso dominio) ele pega os dados da view e passa para o modelo

Pedro vc poderia me explicar?

#10

Erick,

O papel do controller no MVC é dizer de qual VIEW veio a request e após o processamento para qual VIEW ele vai.

No JSF existe o FacesServlet que faz esse papel interpretando o faces-config.xml, sendo assim, você não precisa implementar o controller ele já é implementado de forma transparente pelo Framework.
Exemplo da configuração do faces-config.xml:

<navigation-rule>

  <from-view-id>/greeting.jsp</from-view-id>

  <navigation-case>
    <from-outcome>success</from-outcome>
    <to-view-id>/response.jsp</to-view-id>
  </navigation-case>


  <navigation-case>
    <from-outcome>fail</from-outcome>
    <to-view-id>/fail.jsp</to-view-id>
  </navigation-case>

</navigation-rule>

PS: eu fiz um embolado ontem, no JSF2 esse controle de fluxo é transparente. (Implícito).

Managed Beans - são POJOs gerenciados pelo container do framework, ou seja são classes java normais que mantém estado e comportamento, são nessas classes que você aplica o seu modelo.

Converters e Validators - também são gerenciados pelo container, são classes que implementam as interfaces Converter e Validator do JSF e são invocadas no momento de validação e aplicação de valores ao Modelo dentro do ciclo de vida do JSF.


post: http://www.guj.com.br/posts/list/130642.java

O controle que você implementa nos managed beans tem haver com a resposta a uma ação acionada em sua VIEW com a transição de estado da aplicação, Não com controle de fluxo.

Espero que tenha ficado mais claro.

#11

To começando a entender, veja bem

"O papel do controller no MVC é dizer de qual VIEW veio a request e após o processamento para qual VIEW ele vai. "

Eu nunca trabalhei com JSF1.2 só com o JSF 2.0

quando eu dou subtmt em uma pagina, redirecionamos os valores para algum MB,

ou seja é o MB que recebe esses dados, e redireciono para outra pagina apenas fazendo return"nome da pagina" , o MB recebeu a requisição e retornou,

pra mim isso é o controle não consigo intender , porque isto não é o papel do controle

#12

[quote=PedroTOliveira]Erick,

O papel do controller no MVC é dizer de qual VIEW veio a request e após o processamento para qual VIEW ele vai.

No JSF existe o FacesServlet que faz esse papel interpretando o faces-config.xml, sendo assim, você não precisa implementar o controller ele já é implementado de forma transparente pelo Framework.
[/quote]

Eu discordo desse ponto. Não é transparente, o MB é quem explicitamente decide qual o outcome da operação (da mesma forma que o Action faz no Struts). E eu entendo que esse papel é de Controller. O que muitas vezes ocorre em JSF é os MBs acabarem virando uma mistura de View, Model e Controller.

#13

Então,

O controle que você implementa nos managed beans tem haver com a resposta a uma ação e com transição de estado da aplicação e não com controle de fluxo.

Dentro de uma action eu posso acionar um ou mais serviços de Domínio que podem atualizar N databases e ao mesmo tempo alterar o estado de um UIComponent e ao final retornar um ID que pode representar sim o ID da VIEW que será a próxima a ser renderizada, mas quem faz o papel de procurar essa view e montar é o FacesServlet.

Dá uma lida nessa página aqui para você entender o que cada parte do MVC deve fazer:

#14

No JSF2 existem também outras formas de se mapear a navegação além da forma implícita, a forma implcita dá a idéia de que o papel de controller está sendo feito pelo MB, mas isso não é verdade, na verdade ainda existe um FacesServlet fazendo esse papel em background.

Outras formas de configurar a navegação:

#15

Gente esse artigo aqui explica de forma legal os patterns contidos dentro do Framework JSF.

Vale a pena ler.

#16

Blz então , e o modelo segundo o primeiro link

“The model is not a database: the ‘model’ in MVC is both the data and the business/domain logic needed to manipulate the data in the application. Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Active Record is an accepted design pattern which merges domain logic and data access code - a model which knows how to persist itself.”

O modelo é a logica de negocio/ o dominio da aplicação

No caso o dominio da minha aplicação é a classe Pessoa não o MBPessoa

então o modelo seria a classe Pessoa

#17

[quote=erickfm8]Blz então , e o modelo segundo o primeiro link

“The model is not a database: the ‘model’ in MVC is both the data and the business/domain logic needed to manipulate the data in the application. Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Active Record is an accepted design pattern which merges domain logic and data access code - a model which knows how to persist itself.”

O modelo é a logica de negocio/ o dominio da aplicação

No caso o dominio da minha aplicação é a classe Pessoa não o MBPessoa

então o modelo seria a classe Pessoa[/quote]

“the ‘model’ in MVC is both the data and the business/domain logic needed to manipulate the data in the application.”

Se vc quer separar seu modelo entao são as duas classes:

Pessoa - Dados e Lógica do Domínio de Negócio
MBPessoa - Dados e Lógica da Interface

Em uma arquitetura em camadas, os dados podem muitas vezes ser representados e tratados de forma diferente entre as camadas.

#18

Ah sim agora intendi o conceito MVC, isso é mtu confuso
tudo mundo pensa que o modelo é o dominio e o controle é o MB

Entendi agora Pedro,

Mais voltando la no meu primeiro post do tópico em relação a aqruitetura, eu sei que cada caso é um caso, mais qual seria a mais correta

#19

Pedro,

Eu entendo MVC assim como creio que você deva entender também. Portanto, você deve saber que MVC não quer dizer “1 classe é Model, 1 classe é View e 1 classe é Controller”. MVC representa uma separação de responsabilidades em 3 conceitos que podem ser individualmente implementados por mais de uma classe, mas não deveriam ser misturados na mesma classe (aí vira outro pattern!).

O Faces Servlet atua como Controller sem dúvida. Mas quando um MB retorna um outcome para o navigation handler está também atuando como Controller.
Quando um MB expõe métodos actionListener e valueChangeListener está atuando como View.

E quando ele encapsula dados do domínio atua como Model…

Eu vejo uma vantagem em separar essas responsabilidades em MBs diferentes. Minha opinião pessoal.

#20

Eu entendo que em ambos os casos são trocas de mensagens entre os Objetos. Eles trocam mensagens e até podem ter estados parecidos mas as responsabilidades e comportamentos são diferentes.

Quando o MB retorna um outcome ele está expondo para o Controller o resultado da uma mudança de estado após a execução de uma ação. Quem vai decidir o que fazer a partir dai é o Controller.
Quando o MB expõe métodos actionListener e valueChangeListener esta atuando da mesma forma, quem vai decidir qual pagina será renderizada é o Controller e quem vai exibir é a VIEW.

Não vejo onde as responsábilidades estão misturadas ai.

Concordo, isso tbm vale para o resto das classes do sistema, gerenciadas ou n~ao pelo JSF. :slight_smile: