Pessoal, é possivel aplicar MVC sem utilizar nenhum framework, se sim recomendam algum artigo e ou tutorial?
vlw
É possível sim, nesta apostila tem um tópico sobre MVC
http://downloads.caelum.com.br/apostila/caelum-java-web-fj21.pdf
O uso de frameworks apenas facilita a aplicação do padrão MVC.
[quote=javamail]Pessoal, é possivel aplicar MVC sem utilizar nenhum framework, se sim recomendam algum artigo e ou tutorial?
vlw[/quote]
A forma mais simples e comum de aplicar MVC em um projeto web sem nenhum framework seria:
Model: classes java/Javabeans
Controller: Servlets
View: JSP
Para mim seria.
Model: Classes modelo mesmo (POJO)
Controller: Facades (classes Java mesmo mas com as definições das regras)
View: JSP/Servlets
Servlets serviriam como uma forma de tratar as informações da view, ou seja, seria uma camada de anterior para desacoplar da parte da regra de negócio (Controller/Model). Imagina se depois vc for trocar de Servlet para Struts. Iria ter que mecher além de view em código de controller (Servlet), iria causar um acoplamento muito alto.
[quote=jakefrog]Para mim seria.
Model: Classes modelo mesmo (POJO)
Controller: Facades (classes Java mesmo mas com as definições das regras)
View: JSP/Servlets
Servlets serviriam como uma forma de tratar as informações da view, ou seja, seria uma camada de anterior para desacoplar da parte da regra de negócio (Controller/Model). Imagina se depois vc for trocar de Servlet para Struts. Iria ter que mecher além de view em código de controller (Servlet), iria causar um acoplamento muito alto.[/quote]
Regras de negócio devem ficar no Model e não no Controller. O Controller faz apenas o “leva e traz” entre Model e a View.
[quote=rlazoti][quote=jakefrog]Para mim seria.
Model: Classes modelo mesmo (POJO)
Controller: Facades (classes Java mesmo mas com as definições das regras)
View: JSP/Servlets
Servlets serviriam como uma forma de tratar as informações da view, ou seja, seria uma camada de anterior para desacoplar da parte da regra de negócio (Controller/Model). Imagina se depois vc for trocar de Servlet para Struts. Iria ter que mecher além de view em código de controller (Servlet), iria causar um acoplamento muito alto.[/quote]
Regras de negócio devem ficar no Model e não no Controller. O Controller faz apenas o “leva e traz” entre Model e a View.[/quote]
Ao se usar DDD é algo a se pensar.
Falando de DDD pendo que sua regra de negócia ficariam nos Facades. Se vc vai coloca-lo como controller ou model é apenas nomeclatura. Para mim, ele é mais controller do que modelo.
Se vc olhar um pouco mais a fundo, vai ver que o cliente não deve ver diretamente o controller, por isso coloco Servlet como view e Facade como controller e ele sim aciona as classes do nosso modelo. Se vc precisar saber o gasto total dos clientes vc chamaria um facade para fazer isso.
facadeContas.getTotalGastoClientes();
// e dentro método teria o calculo envolvendo isso.
for(Cliente cliente: clientes)
total += cliente.getGasto;Tudo bem, eu sei que isso poderia ser feito em um select, mas é apenas um exemplo de como o Facade se relaciona com o Modelo. Se vc vai definí-lo como Controller ou Modelo, fica ao seu critério. Sei que DDD isola ainda mais o conceito de regra de negócio no modelo, mas é pq o Servico/Repositório é mais considerado como modelo do que controller.
Se vc notar, o Facade é como um “Controlador” dos modelos.
http://www.allapplabs.com/java_design_patterns/facade_pattern.htm
Onde em DDD fala que pode/deve ter as regras de negócio em Facades?
Pelo menos no livro do Evans jamais vi esta afirmação.
Veja o texto abaixo retirado do link: http://java.sun.com/blueprints/patterns/MVC-detailed.html que mostra como aplicar MVC em uma aplicação web (como o texto é da finada Sun, é logico que eles irão sugerir EJB :D).
“Web-based clients such as browsers. JavaServer Pages (JSP) pages to render the view, Servlet as the controller, and Enterprise JavaBeans (EJB) components as the model. The Java Pet Store sample application illustrates this strategy.”
Com relação ao Facade que você citou entendo que assim como todo design pattern, ele deve ser aplicado somente em determinadas situações e por isso existem catálogos que explicam em quais situações determinado pattern pode ser aplicado.
[imo] Nem sempre aplicar patterns em um projeto é sinônimo de um bom design e se aplicado sem necessidade apenas irá acrescentar complexidade desnecessária. [/imo]
Muito bom, tambem precisava tirar essa duvida da minha cabeça 8)
:?: Pensando bem acho que ainda não sanei completamente minha duvidas… :?:
As classes que fazem consulta ao banco e processam seu resultado para enviar para o servlet controler, são controler tambem ou model?
Vc terá que ter uma classe para ter suas regras de negócio. Se vc quer chamá-la de Facade, Application Layer fica ao seu critério. Não é só pq vc usa DDD que não pode usar nomeclaturas de outros Design Patterns, cabe vc decidir como utilizá-la. Eu conheço gente que utiliza padrão de DDD mas com os nomes que eles mesmos determinaram. O que eu quero falar é que eu vejo controller como quem aplica as regras utilizando o modelo. Modelo define a função de cada um, Controllers decidem o que fazer com o conjunto. A vantagem de DDD é aplicar uma camada a mais até o banco de dados, e isso é muito bom. [=
Se vc utilizar desse modo e depois quiser implantar JSF ou Struts, qual seria o impacto na sua aplicação? Seu servlet além de tratar dados de chegadas da View terá que preparar as informçaões para tratar nas regras de negócio.
Se eu fosse a Sun, faria a mesma coisa pois assim vc está amarrando a sua aplicação às soluções por eles fornecidas. JSP e Servlet estão fazendo papel de receber informação e enviar informações tratadas, para mim da no mesmo que view. EJB vc poderia definir seus entities beans como quem recebe a informação e as envia. @Stateless seriam quem realiza operações, isso para mim da na mesma de um controller pois ele realiza sua rotina e sai de cena. Já o model mesmo ele define como POJOs e POJI apenas com anotattions. Eu ainda estou estudando mais sobre EJB (próxima certificação a vista).
Como vc faz seu padrão e vc qm decide, se vai definir Facade como controller ou model tanto faz desde que ele mantenha o papel que um Facade tenha que exercer.
Então você chamaria uma classe com regras de negócio de Flyweight ou Iterator ou até mesmo de Proxy? :shock:
Novamente pergunto, poderia me mostrar de onde tirou essa afirmação sobre DDD?
Não entendo porque você insiste tanto em citar DDD em um tópico onde estamos discutindo apenas como aplicar MVC.
Creio que muito pouco impacto, pois como falei o Servlet que tem o papel de Controller, apenas faz o leva e traz entre a View e o Model. De uma visão simplista bastaria substituir o Servlet por uma Action do Struts ou um ManagedBean do JSF.
EJB Stateless como Controller? :shock:
[quote=jakefrog]
Como vc faz seu padrão e vc qm decide, se vai definir Facade como controller ou model tanto faz desde que ele mantenha o papel que um Facade tenha que exercer.[/quote]
Eu não fiz esses padrões, eu apenas os utilizo em determinadas situações.
E é muito mais fácil um desenvolvedor identificar um padrão aplicado a uma classe que se chama XPTOFacade do que uma chamada XPTO.
Bem se na sua visão esses nomes derem a entender um controller. Para mim, não mesmo! :shock: Mas ao ler Facade quem tem noção de Design Pattern sabe do que estamos a falar.
Vou ser honesto. Nem eu! Mauhau Foi mals mesmo, prometo não falar mais de DDD! Mas quando eu digo uma camada a mais, eu digo com relação ao MVC. As camadas em DDD são: 1. Camada de Interface com o Usuário (User Interface) 2. Cama de Aplicação (Application Layer) 3. Domínio (Domain Model) 4. Camada de Infra-estrutura . Por isso digo camada a mais. [=
Bem cara, quando eu fiz esse trabalho que estou a te falar, Eu tinha servlet como view e Facade como controller. E foi facil, agora se o código do controller estivesse fazendo parte do servlet, nem sei se teria conseguido fazer o trabalho todo viu.
Se adotar um Controller como alguém que faz a ação e some do mapa? (Até onde estudei, 70pgs do ejb3 =P) Eu vi o Statelles fazendo um papel de pegar um objeto do modelo e dar um fim nela.
[quote=rlazoti]
Eu não fiz esses padrões, eu apenas os utilizo em determinadas situações.
E é muito mais fácil um desenvolvedor identificar um padrão aplicado a uma classe que se chama XPTOFacade do que uma chamada XPTO.[/quote]
Concordo contigo! =D