Se os "criadores" do CI trabalham de forma errada, porque algum de nós faria 
diferente? Fiquei com a pulga atrás da orelha agora em relação ao CI :(
  ----- Original Message ----- 
  From: Vinicius Cruz 
  To: CodeIgniter Brasil 
  Sent: Thursday, February 05, 2009 3:00 PM
  Subject: Re: [CodeIgniter] MVC de verdade


  Acho que aprendi tudo errado ... O_o


  O sistema aqui do trampo tá igual ao Bamboo.


  2009/2/5 Luciano Soares <[email protected]>

    Mais informações

    http://java.sun.com/blueprints/patterns/MVC-detailed.html

    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. 


      a.. 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. 
      b.. 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. 
      c.. 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. 




    2009/2/5 Luciano Soares <[email protected]>

      Bom nesse link da wikiedia em ingles explica o tradicional modelo MVC 
(que é diferente daquele implementado pelo CI devido as restrições de não 
criãção de observers em PHP)

      http://en.wikipedia.org/wiki/Model-view-controller

      As a design pattern
      MVC encompasses more of the architecture of an application than is 
typical for a design pattern.[citation needed]

        Model 
        Is the domain-specific representation of the information on which the 
application operates. Domain logic adds meaning to raw data (for example, 
calculating whether today is the user's birthday, or the totals, taxes, and 
shipping charges for shopping cart items). 
        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. 
        View 
        Renders the model into a form suitable for interaction, typically a 
user interface element. Multiple views can exist for a single model for 
different purposes. 
        Controller 
        Processes and responds to events (typically user actions) and may 
indirectly invoke changes on the model. 


      2009/2/5 Luciano Soares <[email protected]> 


        Controladores se preocupam apenas com o fluxo das operações dentro de 
um modelo MVC.

        O modelo é onde ficam as regras de negócio.


        2009/2/5 Cairo Noleto <[email protected]>

          No Rails, os métodos de um controller são chamadas de actions, que 
realmente passam a ação do que se vai fazer, em um crud temos as seguintes 
ações: 

          Create, Read, Update e Destroy.

          no rails teríamos os seguintes métodos

          def index
          end
          def new
          end
          def edit
          end
          def save
          end
          def destroy
          end
          def show
          end

          Isso seria as ações da aplicação.

          "Um colaborador pode criar uma nova venda" sales/new
          "Um colaborador pode vizualizar uma venda" sales/1/show
          "Um colaborador pode editar uma venda" sales/2/edit
          "Um colaborador pode excluir uma venda" sales/1/destroy

          Claro que isso é a grosso modo, hoje existe formas melhores de se 
fazer isso no rails usando o conceito de rest web service. Mas idéia é 
justamente essa, fazer com que um determinado controle expresse apenas as ações


          2009/2/5 Cleyverson Costa <[email protected]>

            Eric, 


            De tudo o que ja li, o uso correto é da seguinte forma:

            Model >> Aqui tem basicamente as chamadas ao BD. Pense na se 
seguinte situação. Opa minha empresa vai mudar de banco de dados, entao as 
consultas SQL deverao ser modificadas. Se vc tiver no model apenas as chamadas 
ao banco, vc modifica apenas esta camada. Vc modifica os sql e todo o resto 
continua funcionando.

            Controller >> Aqui ficam as regras de negocio e validações etc. 
Tudo fica aqui. Esta é sua camada de negocio.

            View >> Aqui fica a apresentação. Muita gente acaba colocando o 
utf8_encode/decode na view, mas acho que nao seria uma boa pratica. Quanto mais 
limpo vc puder deixar a view (usando o controller) melhor. 

            Depois de muito apanhar esta foi a forma que eu acabei achando como 
mais correta. Estou usando esta estrutura no site www.ezmatch.net caso queira 
dar uma olhada.

            Abraços


            2009/2/5 Eric Saboia (Fortes Informatica) 
<[email protected]>

              Pessoal, pedi antes de ontem um exemplo de aplicação bem feita em 
CI, me indicaram o http://www.bambooinvoice.org/ . Eu estava querendo checar o 
uso do MVC dentro de uma aplicação em CodeIgniter, mas me deparei com o mesmo 
"erro" que julgava estar acontecendo aqui na empresa. O controller tá cheio de 
regras de negócio, assim como validações e etc. Isso tudo não deveria estar no 
Model? Pois até onde sei o modelo representa tanto a persistência, quanto o 
negócio, enquanto o Controller é responsável unicamente pelo fluxo da aplicação.

              Opniões?

              Eric Saboia
              Desenvolvimento Web
              Fortes Informática (Fortaleza)
              Fone: (85) 4005-1111
              [email protected]
              www.grupofortes.com.br


              _______________________________________________
              Lista mailing list
              [email protected]
              
http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br




            _______________________________________________
            Lista mailing list
            [email protected]
            http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br






          -- 
          Cairo Noleto
          =========
          Cairo'sBlog - http://www.caironoleto.com/
          Web developer - Add4 Comunicação - http://www.add4.com.br/



          _______________________________________________
          Lista mailing list
          [email protected]
          http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br









    _______________________________________________
    Lista mailing list
    [email protected]
    http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br






------------------------------------------------------------------------------


  _______________________________________________
  Lista mailing list
  [email protected]
  http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
_______________________________________________
Lista mailing list
[email protected]
http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br

Responder a