Arquivo Discussoes de Programacao e Tecnologia Dae pessoal estou com algumas dificuldades em entender este framework!!! ou seja o seu ciclo onde começo…o que faço é começar criando as classes e a camado DAO, dai… o problema pra onde vou…gostaria que alguem me desse uma sugestão para onde vou e como posso configurar minhas páginas!!!..
valew!! :?: :?: :?:
O Struts é um framework para a camada de View! Pesquise sobre o modelo MVC para entender um pouco melhor…
Ela se “limita” a ajudar a pegar os dados da tela, e chamar a “entrada” do teu controle. E depois, pra página “voltar”.
Pra DAO, modelo, etc etc etc, é outro esquema. Eu uso o Hibernate para este outro lado.
na www.infoq.com tem um ebook sobre o Struts 2. La tem tudo sobre o seu funcionamento e arquitetura
tem também o site www.roseindia.com que tem um pouco de Struts 1.x e 2.x
Bom eu conheço bem MVC…Só que minha real dificuldade, é o controler… me perco no meio onde tenho o controler o action…etc…etc…etc… entende… e como mapear no struts-config e no tiles…
:roll:
No site da Devmedia, caso você seja assinante, tem um curso de Struts bacana tbm, sem falar nos artigos que o Fernando Lozano escreveu sobre Struts com Tiles…
Apostila básica de Struts 1.x em português: http://java.danieldestro.com.br
Bom eu conheço bem MVC…Só que minha real dificuldade, é o controler… me perco no meio onde tenho o controler o action…etc…etc…etc… entende… e como mapear no struts-config e no tiles…:roll:
O Struts NÃO É O CONTROLLER. Você criará o seu próprio controle, que será chamado pelo Action.
Por exemplo, o método action chamada seus facades, seus delegates, ou sei lá quais classes de controle suas. Mas isso não é gerenciado pelo Struts. Do Action pra dentro, o problema é todo seu =P
Sua dificuldade no struts-config, só postando uma por uma. Mas vc pode ver que ele serve para criar Beans e Actions (os seus formulários HTML e as ações associadas a botões HTML, respectivamente). Encare como se o struts “transformasse” HTML em java; quando o programa pára no Action, tem o formulário fofolete, preenchidinho, e vc pode chamar qualquer código java dali pra frente.
Calma lá.
SIM, o Struts implementa um Front Controller, ou seja, ele é sim o controle da aplicação.
Ele não implementa a camada de MODELO do MVC.
Bom pessoal obrigado pela atenção de cada um, mais eu ainda bato o pé que o struts tem um dedinho na camada de controle quer queiramos ou não, estou quase que entendo , meio aos trancos e barrancos, graças a atenção e disposição dos senhores, muito obrigado e se possível continuem me ajudando desde já agradeço novamente a todos valews!!! :roll:
Dedinho? Ele é A camada de controle quando você o usa. Ele é responsável pelo"V" e o"C" do tal do MVC2
Yes’ sir, verdade concordo em genero e grau e numero…dale MVC2
como assim ele não é?
o q action é então se não um controller?
se vc delegar ou chamar um facade o q vc está fazendo é passando responsabilidades, mas quem vai chamar a parte da view é o struts atravez do action não esses caras.
Outra quando eles o xpto devolverem o resultado é o action que vai passar para o form os objetos não os xpto que fez a lógica. só por esse motivos já podemos disser que o struts é um MVC.(velho e ultrapassado, comparado com os novos)
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {
String dispatch = mapping.getParameter();
if( dispatch.equalsIgnoreCase("inicio") ){
iniciar( contratoMAForm, request);
} else if ( dispatch.equalsIgnoreCase("pesquisar") ){
pesquisar( contratoMAForm, request);
}
return mapping.findForward( dispatch )
}
Sorriso, dá uma lida nessa apostila…
Caraaaaaaaaaamba, como essa thread cresceeeeeeeu! Ok, eu devo estar com alguma definição muito errada do que é o controle, mas o facade/delegate sei lá mais o que não é seu controle TAMBÉM? Ou só é controle o action??
Estou em um projeto onde os desenvolvedores aplicam os padrões de forma totalmente equivocada do seu propósito original, ou então eles criaram seus próprios padrões com mesmo nome dos padrões de mercado, hehehehehe. Eu mando refazerem tudo de novo. Isso, para mim, espelha uma coisa: FAZER SEM SABER O QUE É, COMO FUNCIONA E PARA QUE SERVE.
Nada que uma boa leitura ou estudo não resolva:
Front Controller:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
Struts Controller:
http://www.allapplabs.com/struts/struts_controller.htm
http://rollerjm.free.fr/pro/Struts11.html
http://www.roseindia.net/struts/understanding_struts_controller.shtml
Conceituação de Struts - bem legal:
http://www.softwaresummit.com/2003/speakers/AshleyStrutsController.pdf
MVC:
Blz, Daniel, já até conhecia algumas dessas páginas 8)
Mas ainda não respondeu a minha pergunta. Isto é, lendo essas coisas não me fizeram mudar minha visão de que controle da aplicação inclui as outras coisas.
Na verdade, eu sou da sincera opinião que uma coisa no programa ou é model, ou é view ou é controle, está errado isto??
Bom eu aprendi que o Controller é o Struts-Config e lendo um dos links passados (http://www.allapplabs.com/struts/struts_controller.htm) tenho a impressão que ele diz a mesma coisa como o trecho abaixo:
The execute() method is called by the controller when a request is received from a client. The controller creates an instance of the Action class if one doesn?t already exist. The strut framework will create only a single instance of each Action class in your application.
Vale lembrar que essa é minha opnião e não a verdade universal então manerem 
Depende! Se você implementa o modelo MVC, sim. Caso contrário, vai depende do modelo de camadas que você implementa.
No Struts, existe um Servlet, que é a classe org.apache.struts.action.ActionServlet que atual como o Front Controller deste framework.
http://struts.apache.org/1.x/userGuide/building_controller.html
4.2 - The ActionServlet
For those of you familiar with MVC architecture, the ActionServlet represents the C - the controller. The job of the controller is to:
* process user requests,
* determine what the user is trying to achieve according to the request,
* pull data from the model (if necessary) to be given to the appropriate view, and
* select the proper view to respond to the user.
Our controller delegates most of this grunt work to the Request Processor and Action classes.
Como o texto oficial diz, o ActionServlet é o C do MVC.
Coisas como o ActionForm, JSP, TagLib, fazem parte do V do MVC.
E eu entendo que a Action (DispatchAction) seja a implementação de um Command.
O struts-config.xml é só um arquivo de configurações que o framework Struts.
Tô pipocando o google atrás disso, achei isto aqui que eu gostei disso
e desse
http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
Que aí explicaram melhor a minha dúvida. Para mim, o M de model eram apenas a camada de persistência desenhada neste último. E o C de control era o camada de nógócio. Pelo que eu tenho visto nesses links, a camada de negócio está dentro do M, isto?
Por exemplo, pra mim era:
Mas aparentemente não é nada disso e eu estava bem enganada, e parece ser isso:
Mas veja, eu tenho duas coisas distintas: um carinha que “manda” salvar “algo”. No meu caso, um método qualquer que vem do facade e vai pra outro método que dá o “em.persist()” de um objeto que é uma entidade. Um apenas “executa” coisas, o outro “guarda” coisas, e ainda assim eu considero esses dois no mesmo balaio??É isso mesmo???
Ok, até aí eu cheguei hahahaha Minha pergunta deveria ser “mvc é uma arquitetura que engloba O SISTEMA TODO, não?”
Agora sim… Isso mesmo!
Embora você possa usar tanto Servlet quanto JSP para implementar um controlador ©, que é o caso do Servlet ActionServlet do Struts. Mas, em geral, JSP e Servlet serão VIEW.
Para mim, um sistema vai além do código Java. Envolve o banco de dados, a infra-estrutura física (servidores), etc.
Um modelo comumente usado para sistemas web utiliza o MVC2.
Estou em um projeto que é basedo no MVC com 5 camadas.
View - (Struts/JSP/etc)
Controle - (Struts)
Model - (o resto)
E divido nas camadas:
Service (Web Sevices e outros serviços externos)
Web (View)
Application (regras da app)
Business (regras de negócio)
Model (modelo e persistência)
Sim, eles fazem parte das Regras de negocia da sua aplicação no caso nosso MODEL do MVC
Certo, mano…
Um modelo comumente usado para sistemas web utiliza o MVC2.Estou em um projeto que é basedo no MVC com 5 camadas.
View - (Struts/JSP/etc)
Controle - (Struts)
Model - (o resto)E divido nas camadas:
Service (Web Sevices e outros serviços externos)
Web (View)
Application (regras da app)
Business (regras de negócio)
Model (modelo e persistência)
Tá, mas vc vai concordar comigo que o M de model é “grande” (grande no sentido que é nisso que gastamos muito do nosso tempo). Você poderia “desenhar” pra mim o esse quadro, mais especificamente “Application”, “Business” e “Model”, o que seria EXATAMENTE cada um e como interagem? (Por desenhar entenda-se passar links, apostilas ou referências, porque buscando assim por alto não achei boas explicações)
Obrigadinha!
Tá, blz, isso eu percebi. Mas acho esquisito não separar os dois, entende?
P.S. - Não sei se conseguirei ver essa thread novamente até amanhã.
Pessoal alguem pode me explicar a diferença da configuração no Struts.
Web.xml e Struts - Config.xml
Pessoal alguem pode me explicar a diferença da configuração no Struts.
Web.xml e Struts - Config.xml
web.xml é a configuração de uma aplicação web JEE.
struts-config.xml é a configuração do framework struts.
ou seja o web.xml sempre terá em todos os seu projeto web JEE
xpto.xml só vai existir dependendo do framework.
Ok, mas qual o problema de ser “grande”?
Isto vai variar de acordo com o tamanho do seu modelo, negócio, requisitos, etc.
As camadas que eu criei: Application, Business e Model, foram uma forma de eu melhor adptar uma arquitetura às características e aos requisitos do nosso projeto de sistema todo. Não tem nada de “padrão de mercado” nisso.
Mas, basicamente, são serviços EJB distribuídos se comunicando, com JPA na persistência.
Cintia, no nosso caso estamos falando de arquitetura ou padrão(dependendo da região que vc vem) MVC logo Tudo relacionado ao a regras, requisitos, validação, etc vai estar dentro do Model.
agora se começarmos a falar sobre regra de negocio, domínio da aplicação, requisitos, diagrama de classe, uml… essa objetos começam a ter seu espaço. e outro sentido além do nosso contexto, entende?
Não, eu não entendi a resposta de vocês dois porque provavelmente não consegui fazer uma pergunta boa o suficiente. As respostas tão meio distantes das minhas dúvidas, então é certamente algum conceito perdido no meio do caminho. Mas uma hora eu conseguirei entender o que eu não sei e tento de novo.
Ok, eu aceito que chamam “isso” de model. Afinal, caneta tem que chamar caneta para que os outros entendam o seu significado. Se eu chamar caneta de livro não adianta em nada e atrapalha toda a lógica de comunicação.
Eu tb entendo que cada sistema/pessoa requer/deseja ter uma arquitetura ligeiramente diferente, eu só me perdi mesmo neste tópico e estava perguntando algo do tipo “mas e como vcs fazer do Action pra dentro? Dividem em mais camadinhas? Ou só módulos que se comunicam? E o que vcs acham disso? Etc etc etc”. Mas afinal não sou expert em patterns e pode ser por isso. Pra mim, muitas vezes mais parece sopa de letrinhas.
Mas obrigada pelas explicações mesmo assim!
no projeto que estou faço Regras de negocio dentro do action, mas nada impede de vc trabalhar em outro objeto Log.Neg…
camadas, sim seu DAO ou Repositorio, seus facade/delegate pode ser mais uma camada.
é mta das coisa que sai nova e milhares que já existem formam essa sopa de letrinhas juntar tudo de uma vez dá uma prato ruim de mais…rs
não sou expert tbm, mas espero poder ter ajudado…
abr
Eu pensei, pensei, gastei meus neurônios e acho que descobri o que eu tinha me perdido.
Até então, eu tinha certeza que MVC eram os nomes das TRÊS CAMADAS do sistema, e não sei lá, uma CLASSIFICAÇÃO das suas camadas.
E daí o Daniel falou que tinha um MVC de 5 camadas, e me perdi no caminho… Porque eu até já tinha lido sobre isso, mas não tinha feito muito sentido. Vejam se AGORA o meu raciocínio está certo:
Você tem N mil camadas na sua aplicação, de acordo com o gosto do freguês. Mas cada uma delas poderia ser encarada com uma parte do M, do V ou do C, e o MVC te diz COMO ELAS INTERAGIRIRIAM entre elas!
É isto, pessoas?
Eu já tinha pensado isso faz uns dias, mas esquecia de postar aqui.
Sim o MVC diz como interagis com elas, mas o responsavel unir os dois(M/V) é a parte controller sempre.
as N camadas já fazem sempre parte do model…
A view pode ser mudado para um outro componente que atende o framework(ex.:JSF(IceFaces, Richfaces, ajax4jsf) ou FLEX)
mas Controller é a infraestrutura(caixa fechada), que nem eu nem vc tem como mudar só utilizar ou configurar, então vc presisa dar “vida” programar/configurar ele para trabalhar com o a parte model e a view.
Ex.:
Struts tem Action/Form/API/XML
Spring tem API/Annotation/XML
Hibernate tem XML/Annotation
Vraptor tem API/Annotation/XMLs
o que está fora dos ‘tens’ são model e view, assim o que passa do que é controller(API do FrWk) já caracteriza o model o view…
espero que mais Brother opinem…
se não consegui te ajudar acho que não sou a pessoal mais indicada para responder.
abr
uma outro ponto de vista sobre MVC. http://sergiotaborda.wordpress.com/java/patterns/mvc/