Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Andréa, acredito que o melhor conselho seria indicar leituras sobre MVC:
http://java.sun.com/blueprints/patterns/MVC.html
http://java.sun.com/blueprints/patterns/MVC-detailed.html
Esse é o padrão mais usado para o desenvolvimento de aplicações web e com ele vc pode criar três camadas (Model-View-Controller) com o maximo de desacoplamento entre si. Vale tambem uma olhada no padrão DAO. Usando esse pattern vc fica menos engessada ao banco de dados. Se algum dia mudar seu banco, vc muda apenas os DAOs e pronto. Nos beans, que são a camada de Model, vc usa os DAOs. Outra vantagem é que fica mais simples usar um pool de conexões.
Esse código, ou melhor, todas as rotinas de negócio devem ficar separadas da camada de apresentação.
Assim sendo, esse código deveria ficar no Bean.
A única coisa que ficam nas JSP's são rotinas para exibição apenas.
Isso torna seu código reusável.
Se um dia disserem que essa aplicação também vai suportar um front-end SWT por exemplo, a camada de negócio está desacoplada da camada de apresentação, isto é: ela poderá ser reutilizada no novo front-end, sem muitas modificações.
Esse é o padrão mais usado para o desenvolvimento de aplicações web e com ele vc pode criar três camadas (Model-View-Controller) com o maximo de desacoplamento entre si.
Jack, o modelo MVC se constitui de uma camada apenas: a de apresentação.
Jack, o modelo MVC se constitui de uma camada apenas: a de apresentação.
Ops... agora viajei. Pelo que sei vc pode criar multiples views sem ter que mudar o controller e o model, alias é esse o proposito do MVC. É claro que o que mais mudará serão as Views mesmo já que vc poderá ter desde um cliente web até um Swing da vida e, claro, as regras de negocio do model geralmente não mudam tanto. Ainda assim MVC é multi-tier, ou não?
Bom, talvez eu apenas tenha usado a palavra "camada" de maneira impropria. É provavel que "modulo" fosse mais correto.
No mais, explica aí, Jean. _________________Marcos Silva Pereira
Então, o MVC é como vc mesmo disse, um modelo de arquitetura que se constitue de um Modelo(Model),Visão(View),Controlador(Controller).
Todos esses ítens fazem parte da camada de apresentação. Muita gente acha que isso realmente é dividido em três camadas. Mas não é bem assim.
O model serve para armazenar os dados, a view para exibir os dados, e o controller para controlar a navegação.
Existem Beans que fazem a função de negócio. Esses não são models. E portanto, esses já fazem parte de outra camada. Os models são geralmente os DTO's. Ou VO's como os mais antigos costumam chamar.
Fica claro se vc verificar que o struts é um framework para a camada de apresentação. Ele utiliza o padrão MVC.
Se não ele seria um framework para a camada de negócios e ou de integração.
Então, o MVC é como vc mesmo disse, um modelo de arquitetura que se constitue de um Modelo(Model),Visão(View),Controlador(Controller).
Todos esses ítens fazem parte da camada de apresentação. Muita gente acha que isso realmente é dividido em três camadas. Mas não é bem assim.
O model serve para armazenar os dados, a view para exibir os dados, e o controller para controlar a navegação.
Existem Beans que fazem a função de negócio. Esses não são models. E portanto, esses já fazem parte de outra camada. Os models são geralmente os DTO's. Ou VO's como os mais antigos costumam chamar.
Fica claro se vc verificar que o struts é um framework para a camada de apresentação. Ele utiliza o padrão MVC.
Se não ele seria um framework para a camada de negócios e ou de integração.
jrodrigues, com o que vc falou fiquei com uma duvida sobre o MVC e o struts,
eu participei de uma palestra umas semanas atrás sobre struts, e o que falaram foi que o struts é um framework que implementa o MVC, mas ele se concentra apenas no view e no controller deixando o model a corga do desenvolvedor. Assim como o Jack eu tb achava que o MVC são três camadas. Não consegui entender pq se refere apenas a camada de apresentação. Vc poderia me explicar melhor e mostrar um exemplo de como seria uma implementação em 3 camadas.
Eu estava tentando colocar um diagrama aqui, mas não deu.
Bem, suponha que vc tem uma aplicação com Struts.
Da camada de apresentação fazem parte o Model, a View, e o Controller.
Da camada de negócios fazem parte Business Logic JavaBeans, e Enterprise JavaBeans.
O Model será basicamente um ou mais DTO's que fazem o transporte da camada de negócios para a apresentação. Há quem considere estes parte da camada de negócio, como também há outros (maioria) que o consideram parte da camada de apresentação, haja visto que sua função é exatamente transportar dados retirados da camada mais baixa com o intuito de exibí-los.
Por isso os Value Objects mudaram de nome, ou estão passando para essa nova nomenclatura.
O Model, a View e o Controller fazem parte da presentation layer.
Os EJB's e Business Logic JavaBeans fazem parte da business layer.
Os RDBMS's geralmente fazem parte da data layer ou resource layer.
Um Data Access Object (DAO) geralmente faz parte de uma integration layer já que a função é desacoplar a camada de negócio da camada de dados.
Os frameworks de persistência também fazem parte da integration layer.
Existem várias formas de vc arquitetar uma solução em N camadas.
Vc pode usar Filters para post-processing e pre-processing de informações antes de elas atingirem o nível do Controller por exemplo.
Mas isso já um outro assunto...
Da camada de apresentação fazem parte o Model, a View, e o Controller.
Pera que ainda não entendi isso direito. É provavel que eu já esteja muito acostumado com a frase "mvc em três camadas" para mudar o conceito assim. Salvo engano isso se chama ressonância cognitiva.
Jean, sob minha concepção, o Model tambem pode ser usado para algo não voltado para view, por exemplo, num bussines 2 bussines da vida. Há até uma referencia sobre isso na descrição do MVC no Blue Prints, no site da Sun.
For example, an online store may require an HTML front for Web customers, a WML front for wireless customers, a JavaTM (JFC) / Swing interface for administrators, and an XML-based Web service for suppliers
Aqui fica claro o conceito de multiple views, mas, não percebo um Web Service como uma das possiveis views. Eu imagino sempre que um web service irá acessar o model e não os DAOs da integration layer. Até porque isso não faz o menor sentido, ora, para onde iriam a regras de negocio?!. Bom, talvez vc pudesse me explicar melhor como é feita a integração entre o model e a business layer. Putz... que nó, eu sempre achei que o model fosse a business layer. Claro, eu nunca vi um sistema usar MVC sem usar pelo menos uns DAOs, FrontController e por aí vai.
For example, an online store may require an HTML front for Web customers, a WML front for wireless customers, a JavaTM (JFC) / Swing interface for administrators, and an XML-based Web service for suppliers
Aqui ficou claro que se tratam de views. Parte da camada de apresentação.
Vamos tentar com perguntas:
- Para que serve o Model?
Responda-me com os conceitos que vc tem. Talvez aí esteja o problema em entender que ele faz parte da camada de apresentação.
Numa unica frase meu conceito de Model é o seguinte:
Modulo(eu ia chamar de camada ) contento a representação dos dados e as regras de negocio.
Numa unica figura:
valeuz...
Concordo com o Jack, tb é isso que penso sobre o Model.
As Views podem ser JSP ou Swing, que para mim é a apresentação, que através de seus respectivos Controllers e conversam com o Model que contêm DTO's mas tb EJB. _________________JavaFree.org Blog
Numa unica frase meu conceito de Model é o seguinte:
Modulo(eu ia chamar de camada ) contento a representação dos dados e as regras de negocio.
Numa unica figura:
valeuz...
Concordo com o Jack, tb é isso que penso sobre o Model.
As Views podem ser JSP ou Swing, que para mim é a apresentação, que através de seus respectivos Controllers e conversam com o Model que contêm DTO's mas tb EJB.
Ainda continuo sem a resposta, pra que servem os DTO's?
Os DTO's servem para as Views mostrarem dados do model, e para mim os DTO's são um recurso da parte do Controller para diminuir as chamdas no Model _________________JavaFree.org Blog
Mais uma coisa.. respondendo a sua pergunta, no Model para mim é onde ficam as regras de negócio.
Não! Model é o que modela o contéudo... ou seja, a informação.
E o que vc faz com isso?
EXIBE! (por isso, faz parte da camada de apresentação)
Regras de negócio NÃO são modelos.
Regras de negócio estão intrinsecamente ligadas com outra camada: a de dados. O DTO não tem nada a ver com a camada de dados. Ele simplesmente transporta a informação que vc quer exibir e que é proveniente de outra camada!!! Será que dessa vez eu fui mais claro? HEHEHEHE ...
Acho que eu não sirvo para explicar isso... Isso tem que ficar claro. Esses conceitos se confundem geralmente quando o pessoal programa mais do que arquiteta soluções.
Não! Model é o que modela o contéudo... ou seja, a informação.
E o que vc faz com isso?
EXIBE! (por isso, faz parte da camada de apresentação)
Regras de negócio NÃO são modelos.
Regras de negócio estão intrinsecamente ligadas com outra camada: a de dados. O DTO não tem nada a ver com a camada de dados. Ele simplesmente transporta a informação que vc quer exibir e que é proveniente de outra camada!!!
Jrodrigues,
De acordo com a organização dos patterns no site da sun, os DTO's fazem parte da camada de negocio
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html _________________JavaFree.org Blog
Ainda não consegui entender esse ponto de vista, Jrodrigues.
Retirei esta frase do site da sun sobre MVC, e para mim é o que por isso que se trata de 3 camadas.
http://java.sun.com/blueprints/patterns/MVC.html
"The Model-View-Controller design pattern solves these problems by decoupling data access, business logic, and data presentation and user interaction. " _________________JavaFree.org Blog
"Participants & Responsibilities
The MVC architecture has its roots in Smalltalk, where it was originally applied to map the traditional input, processing, and output tasks to the graphical user interaction model. However, it is straightforward to map these concepts into the domain of multi-tier enterprise applications.
Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.
View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
Controller - The controller translates interactions with the view into
actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
"
Regras de negócio estão intrinsecamente ligadas com outra camada: a de dados. O DTO não tem nada a ver com a camada de dados. Ele simplesmente transporta a informação que vc quer exibir e que é proveniente de outra camada!!! Será que dessa vez eu fui mais claro? HEHEHEHE ...
Desde quando um DTO faz insert em um RDBMS?
Será que agora parece mais claro?
O que postei me faz pensar que MVC diz respeito a implementação completa de apresentação até regras de negócio, tudo bem que os DTO's~servem para exibir os dados nas views, mas eles são apenas um recurso do Model para transporte dos dados e não que eles sejam o Model. _________________JavaFree.org Blog
"Web-based clients such as browsers. JavaServer PagesTM (JSPTM) pages to render the view, Servlet as the controller, and Enterprise JavaBeansTM (EJBTM) components as the model. The Java Pet Store sample application illustrates this strategy. "
Por exemplo, esta citação do link acima, se o Model é composto por EJB's que é onde devem estar as regras de negocios, como poderia ser parte da apresentação ? _________________JavaFree.org Blog
Regras de negócio estão intrinsecamente ligadas com outra camada: a de dados. O DTO não tem nada a ver com a camada de dados. Ele simplesmente transporta a informação que vc quer exibir e que é proveniente de outra camada!!! Será que dessa vez eu fui mais claro? HEHEHEHE ...
Desde quando um DTO faz insert em um RDBMS?
Será que agora parece mais claro?
Correto DTO's não fazem insert em BD, mas eles não são o Model, fazem parte do model mas são apenas um recurso para transporte de dados. _________________JavaFree.org Blog
"Web-based clients such as browsers. JavaServer PagesTM (JSPTM) pages to render the view, Servlet as the controller, and Enterprise JavaBeansTM (EJBTM) components as the model. The Java Pet Store sample application illustrates this strategy. "
Por exemplo, esta citação do link acima, se o Model é composto por EJB's que é onde devem estar as regras de negocios, como poderia ser parte da apresentação ?
Modelo, como concepção, modela as regras de negócios que ficam nos EJB's. EJB's são parte da camada de persistência. Modelos são DTO's.
DTO's não persistem informação.
Modelos modelam. A camada de negócio possui lógica de negócio.
DTO's não possuem lógica de negócio.
Enfim, não sei se fui claro. Tentei aqui expressar o que eu julgo correto e aceitável do ponto de vista mais técnico de arquitetura distribuída.
Conceitos mudam. Eu acompanho essa evolução. E no presente momento, o conceito que exponho aqui é o mais atual.
"Web-based clients such as browsers. JavaServer PagesTM (JSPTM) pages to render the view, Servlet as the controller, and Enterprise JavaBeansTM (EJBTM) components as the model. The Java Pet Store sample application illustrates this strategy. "
Por exemplo, esta citação do link acima, se o Model é composto por EJB's que é onde devem estar as regras de negocios, como poderia ser parte da apresentação ?
Modelo, como concepção, modela as regras de negócios que ficam nos EJB's. EJB's são parte da camada de persistência. Modelos são DTO's.
DTO's não persistem informação.
Modelos modelam. A camada de negócio possui lógica de negócio.
DTO's não possuem lógica de negócio.
Enfim, não sei se fui claro. Tentei aqui expressar o que eu julgo correto e aceitável do ponto de vista mais técnico de arquitetura distribuída.
Conceitos mudam. Eu acompanho essa evolução. E no presente momento, o conceito que exponho aqui é o mais atual.
Outro detalhe: essa integração modelo-persistência é muito tênue. Não dá pra ser rígido.
Eles existem em um contínuo. Os DTO's fazem parte do Model. EJB's não.
Tem muita gente que diz que faz. Assim como dizem que DTO's são parte da camada de negócio.
DTO's são Models. Se eles fazem parte da camada de negócio ou não é meramente conceitual.
Estes sim geram polêmica em todo o lugar.
Pra mim, DTO's fazem parte da camada de apresentação. Não possuem lógica de negócio para fazerem parte da camada de negócio.
Se sua concepção é diferente, tudo bem.
Vamos ficar debatendo até o fim do mundo, e um não convencerá o outro do contrário.
"Web-based clients such as browsers. JavaServer PagesTM (JSPTM) pages to render the view, Servlet as the controller, and Enterprise JavaBeansTM (EJBTM) components as the model. The Java Pet Store sample application illustrates this strategy. "
Por exemplo, esta citação do link acima, se o Model é composto por EJB's que é onde devem estar as regras de negocios, como poderia ser parte da apresentação ?
Modelo, como concepção, modela as regras de negócios que ficam nos EJB's. EJB's são parte da camada de persistência. Modelos são DTO's.
DTO's não persistem informação.
Modelos modelam. A camada de negócio possui lógica de negócio.
DTO's não possuem lógica de negócio.
Enfim, não sei se fui claro. Tentei aqui expressar o que eu julgo correto e aceitável do ponto de vista mais técnico de arquitetura distribuída.
Conceitos mudam. Eu acompanho essa evolução. E no presente momento, o conceito que exponho aqui é o mais atual.
Concordo que conceitos mudam, mas para mim é impossível concordar com o que vc escreveu sobre o MVC. Gostaria que os outros membros dessem suas opniões a respeito, está com bastante material e principalmente 2 pontos de vista diferentes sobre o MVC.
Dalton e Jack e os outros administradores por favor deem suas opniões já que o MVC é algo bem importante.
Outro detalhe: essa integração modelo-persistência é muito tênue. Não dá pra ser rígido.
Eles existem em um contínuo. Os DTO's fazem parte do Model. EJB's não.
Tem muita gente que diz que faz. Assim como dizem que DTO's são parte da camada de negócio.
DTO's são Models. Se eles fazem parte da camada de negócio ou não é meramente conceitual.
Estes sim geram polêmica em todo o lugar.
Pra mim, DTO's fazem parte da camada de apresentação. Não possuem lógica de negócio para fazerem parte da camada de negócio.
Se sua concepção é diferente, tudo bem.
Vamos ficar debatendo até o fim do mundo, e um não convencerá o outro do contrário.
Não acho que ficaria debatendo assim.. hehehe , eu gosto de conversar com pessoas capacitadas, principalmente quando tem alguma divergencia sobre algo que eu penso, pq a gente se engana, podemos entender as coisas de uma maneira que não seja a ideal.
Desculpe me mas não era minha intenção convercer ninguém do que estou falando e sim te mostrar o que eu penso a respeito do MVC e tntar entender pq que não seria o que acredito. E por isso gostaria, que se por acaso os administradores não respondam, que vc desse um toque para eles responderem para ter opnioes de outras pessoas e não apenas as nossas..
Flw carinha, e quem sabe a gente não se encontra em outro debate.. hehehe _________________JavaFree.org Blog
Dalton, então por favor me de sua opnião enviando para o meu e-mail lap_junior@ig.com.br
O que vc precisa mais do que o post do nosso colega Jean que eu citei acima?
A uns tempos atrás, ainda quando se discutia uma arquitetura para boas práticas de desenvolvimento utilizando Models, se pensava em usar EJB's, mas hoje em dia EJB's nada mais são, do que uma parte da camada de persistência, que pode ser complementada por Frameworks, como Hibernate, OJB etc..
No meu ponto de vista, é simplesmente inaceitável você falar que:
DTO faz insert em um RDBMS
Bem, não vou ficar discutindo algo que está documentado!
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
Pô, eu saio pra almoçar e agora nem sei por onde começar.
Jean, seu malandrão, eu realmente não havia respondido a sua pergunta mas consegui entender onde vc quer chegar. Só que ainda tenho discordancia quanto a sua opinião. Bom, como vc mesmo disse o model serve para modelar o conteudo e tambem para encapsular as regras de negocio sobre essas informações. Mas, acho que pensando assim, intrisicamente, até o proprio banco tem influencia em como os dados estão modelados. O exemplo pode até ser um exagero da visão que vc tem sobre o MVC, mas é o estou conseguindo entender da sua concepção.
Acho que o Model indica quais dados serão mostrados mas não como, isso é responsabilidade da View, seja ela uma jsp, um template ou um cliente swing. Entretanto eu posso acessar o model para efetuar outro tipo de operação não relacionada a uma view ou que sequer seja direcionada a uma view, concorda?! E pô, vamos continuar a discussão que tá legalz...
Andréa MartinsPosts:141
Cá estou eu de novo.... rs
ops:
Bom, buscando eliminar ao máximo cidificação java das minhas páginas Jsp, deparei com uma solução e gostaria da opnião e crítica de vocês...
Antes de criar um Bean para conexão e obtenção de resultados, estou usando includes apenas para fazer "a limpeza".
Ex.:
O que era assim:
<% String nome=""; String codigo =""; String cod = "";
String login = request.getParameter("login");
String senha = request.getParameter("senha");
String sql = "SELECT CLI_NOME,C.CLI_CODIGO FROM CDL_CLIENTE C, CDL_LOGIN L WHERE L.LOG_USUARIO='"+login+
"' AND L.LOG_SENHA='"+senha+"' AND C.CLI_CODIGO = L.CLI_CODIGO;";
try {
Statement s=con.createStatement();
ResultSet rs=s.executeQuery(sql);
if (rs.next()){
nome = rs.getString("CLI_NOME");
codigo = rs.getString("CLI_CODIGO");
cod = codigo.substring(0,1);
rs.close();
s.close();
session.setAttribute("nome", nome);
session.setAttribute("codigo", codigo);
if (cod.equalsIgnoreCase("C")){ %>
<% } else { %>
<% } }else %>
<% }// fecha o try do include
catch (Exception err){ } %>
ficou assim:
<%@ include file="banco/sql_login.jsp" %>
ficando o restante neste arquivo sql_login.jsp.
Mas não estou certa de ser este um jeito razoável de limpar as páginas por causa da manutenção ...
O que sugerem? (Além do Bean que pretendo fazer mais tarde?)
Abraços,
Andréa
jack_-_ganzhaPosts:4191
Andréa, acredito que o melhor conselho seria indicar leituras sobre MVC:
http://java.sun.com/blueprints/patterns/MVC.html
http://java.sun.com/blueprints/patterns/MVC-detailed.html
Esse é o padrão mais usado para o desenvolvimento de aplicações web e com ele vc pode criar três camadas (Model-View-Controller) com o maximo de desacoplamento entre si. Vale tambem uma olhada no padrão DAO. Usando esse pattern vc fica menos engessada ao banco de dados. Se algum dia mudar seu banco, vc muda apenas os DAOs e pronto. Nos beans, que são a camada de Model, vc usa os DAOs. Outra vantagem é que fica mais simples usar um pool de conexões.
Sobre o DAO vc encontra informações em:
http://java.sun.com/blueprints/patterns/DAO.html
Core J2EE Patterns - Data Access Object
Vale tambem uma buscada no forum por posts sobre ambos os padrões. Algumas opiniões serão boas para esclarecer mais ainda as coisas.
valeuz...
_________________Marcos Silva Pereira
jrodriguesPosts:1360
Andréa,
Esse código, ou melhor, todas as rotinas de negócio devem ficar separadas da camada de apresentação.
Assim sendo, esse código deveria ficar no Bean.
A única coisa que ficam nas JSP's são rotinas para exibição apenas.
Isso torna seu código reusável.
Se um dia disserem que essa aplicação também vai suportar um front-end SWT por exemplo, a camada de negócio está desacoplada da camada de apresentação, isto é: ela poderá ser reutilizada no novo front-end, sem muitas modificações.
É isso.
jrodriguesPosts:1360