Hahahahhaha, vou mandar!! ;) 2009/2/9 Rafael V. de Oliveira <[email protected]>
> Ficou claro e objetivo. > > > > Cairo, vc trabalha na ADD4? Junto com o Jesus (vulgo Klederson de Nazaré)? > > Se sim, faz um favor pra mim. Manda ele pro inferno. Estou esperando ele > limpar meu banheiro! > > Se não, deixa quieto. > > > > *De:* [email protected] [mailto: > [email protected]] *Em nome de *Cairo Noleto > *Enviada em:* segunda-feira, 9 de fevereiro de 2009 13:17 Rafael > *Para:* CodeIgniter Brasil > *Assunto:* Re: [CodeIgniter] MVC de verdade > > > > Bom, eu fiz uma explicação breve, talvez mais clara (ou não) sobre MVC no > meu blog > http://www.caironoleto.com/2009/02/09/cuidado-com-model-view-controller/ > > 2009/2/7 Beto <[email protected]> > > essa lista tem ficado cada vez mais interesante! :D > tbm tinha aprendido q as validacoes tinha q ser feito no modelo e nao nos > controles, temos muito pano p manga :D > > []´s > - - - - - - - - - - - - - - - - - - - - - > Luiz Alberto S. Ribeiro [ Beto ] > http://beto.euqueroserummacaco.com > > 2009/2/7 Eric Saboia (Fortes Informatica) <[email protected]> > > > > Não recebi. > > ----- Original Message ----- > > *From:* Marcus Cavalcanti <[email protected]> > > *To:* CodeIgniter Brasil <[email protected]> > > *Sent:* Friday, February 06, 2009 5:24 PM > > *Subject:* Re: [CodeIgniter] MVC de verdade > > > > Mandei com outra thread... em um arquivo anexo, se alguem nao receber, me > avisa.. > > 2009/2/6 Marcus Cavalcanti <[email protected]> > > Vou fazer aqui um exemplo e mando.. > > 2009/2/6 Luciano Soares <[email protected]> > > > > Marcus vc poderia dar um exemplo usando aquele exemplo das cartas de como > vc implemente o Service Layer? > > > > Acho que seria de uma grande ajuda pro pessoal e poderia ser > disponibilizado no site do CI. > > > > Até mais. > > 2009/2/6 Marcus Cavalcanti <[email protected]> > > Esse "scan" da revista diz bem o que estou querendo dizer e o inverso que o > BambooInvoice faz. > > > > 2009/2/6 Marcus Cavalcanti <[email protected]> > > Acadei dando um "send" sem querer, mas continuando.. > > O cachorro que deve conhecer os seus métodos, se ele deve latir alto ou > baixo (regra d enegócio/validação) é ele quem deve conhecer e não a > aplicação, pois isso diz respeito ao cachorro e não a aplicação então qual > sentido de ter isso no controller? > > Quando você tem duas entidades, por exemplo, um método "enviarCarta" você > está dizendo respeito na verdade a duas entidades: carta e pessoa. Pessoa pq > alguém envia uma carta e nesse caso é uma pessoa, então vocês devem estar se > perguntando: Isso fica em qual das duas classes? A resposta é nenhuma, isso > deveria ficar em outra camada, na qual chamam de "Services Layer" que é > responsável por implementar isso. > > Essas questões divergem, tem várias oponiçoes, o negócio é tentar pensar > nas coisas como objetos. Sinceramente o MVC que o CI implementa não é um MVC > como foi proposto, o pattern mesmo, mas é como o CI implementa. > > Eu nunca tenha regras de negócio no meu controller, ou é no model ou tenho > uma camada a mais, conforme já citei. > > Esse é um bom assunto a ser discutido aqui e a propósito eu acho essa app > BambooInvoice um péssimo exemplo. > > 2009/2/6 Marcus Cavalcanti <[email protected]> > > > > hahaha adoro essas discussões... > > Pensando no MVC, o que o Luciano botou é o certo a ser feito. > > Controllers não devem ter regras de negócio da aplicação, controllers não > conhecem isso, apenas direcionam a aplicação. > > Em OO purista e como deveria ser, segundo Domain Driven Design, as > informações e regras de negócio de uma entidade deveriam dizer respeito a > ela e não a um controller, lembre-se, aprendemos OO da seguinte forma: > > class Cachorro extends Mamifero { > public function latir() { > > } > > > 2009/2/6 Eric Saboia (Fortes Informatica) <[email protected]> > > > > > Concordo, > > Só complementando, regras genéricas como "validação, redimensionamento de > uma imagem, apuramento de dados e etc" devem sim ser utilizadas no Model, > porém, se não tem ligação direta com o domínio do model em questão, podem > ficar separadas em um helper ou library. > > > > Não faz muito sentido você dar load em um Model diferente do domínio atual, > só pra aproveitar algum método, melhor é deixar essas regras encapsuladas e > chamar diretamente dentro de cada Model necessário. > > > > Mas isso já diz mais respeito a DDD do que ao MVC em si (eu acho), e é > claro, como tudo que estudamos, é sempre uma sugestão de boa conduta de > desenvolvimento, não estou dizendo que é uma regra ;) > > ----- Original Message ----- > > *From:* Ricardo Valfreixo <[email protected]> > > *To:* CodeIgniter Brasil <[email protected]> > > *Sent:* Friday, February 06, 2009 5:57 AM > > *Subject:* Re: [CodeIgniter] MVC de verdade > > > > > Não existe um papel claro escrito na pedra. Existem ferramentas e práticas. > De uma forma geral , é apenas bom senso. O CI é fabuloso porque nos dá > liberdade para fazermos a aplicação da forma que quisermos. E é mau porque > nos dá liberdade para fazermos a aplicação da forma que quiseres eheheh. > > Com o codeigniter não precisas sequer de usar models e views. Pode > simplesmente usar controllers, fazer chamadas directas ao banco de dados e > produzir echos para visualização. No entanto estão lá as outras estruturas > para nos ajudar a vida. > > Colocar código nos models é uma boa ideia por muitos motivos. Mas vou dar > apenas um para te por a pensar. Se quiseres reutilizar um código (um > qualquer, validação, redimensionamento de uma imagem, apuramento de dados, > etc) onde é mais simples de colocar para ser utilizado em qualquer lado? > > Se for no controlador, terá de usar copy/paste para reproduzir. Enquanto se > estiver num model é apenas fazer load do model e usar o método. > > Para mim e cada vez mais para os utilizadores de arquitecturas MVC a regra > é deixar os controladores o mais magro possível e deixar os models engordar > à vontade. > > Agora a decisão é sempre tua :) > > //Zen > > > > 2009/2/5 Eric Saboia (Fortes Informatica) <[email protected]> > > Cara, eu lembro que já foi discutido sim, mas não especificamente sobre o > MVC, tanto que pra mim (e pelo visto pra maioria aqui) não havia ficado > claro o papel de cada camada. > > ----- Original Message ----- From: "Newton Wagner" <[email protected]> > To: "CodeIgniter Brasil" <[email protected]> > Sent: Thursday, February 05, 2009 5:54 PM > > > Subject: Re: [CodeIgniter] MVC de verdade > > > E é por isso que alguns frameworks criam outra camada além do Model, a > de Persistência. Aí fica mais bem separado ainda! :). > > Realmente essa discussão já foi abordada aqui na lista... quem quiser > pode procurar no histórico. > > > 2009/2/5 Cleyverson Costa <[email protected]>: > > OK Valeu! > > 2009/2/5 Eric Saboia (Fortes Informatica) <[email protected]> > > > Cleyverson, > se você usa Active Record, teoricamente a mudança entre banco de dados é > transparente. além disso, nada impede que você isole as querys das regas de > negócio... da uma lida sobre DDD. > > Valeu! > > ----- Original Message ----- > From: Cleyverson Costa > To: CodeIgniter Brasil > Sent: Thursday, February 05, 2009 3:32 PM > Subject: Re: [CodeIgniter] MVC de verdade > Mas pensem, se eu colocar a validação dentro do model e quiser trocar o > banco de dados...??? > > Isso vai me dar uma grande dor d cabeça... > > Regra de negocio eu chamo de validações, ifs e elses etc que vai dizzer o > que fazer...pra mim nao ta tendo logica isso ficar dentro do model. > > Abraços > > 2009/2/5 Eric Saboia (Fortes Informatica) <[email protected]> > > > 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. > > 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. > > 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 > > > ________________________________ > > _______________________________________________ > 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 > > > > > -- > Newton Wagner > > skype: newtonwagner > msn/gtalk: [email protected] > > http://www.newtonwagner.net/ > - http://www.owshit.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 > > > > > -- > Marcus Cavalcanti > 21 9144-5068 > www.marcuscavalcanti.net/blog > > > > > -- > Marcus Cavalcanti > 21 9144-5068 > www.marcuscavalcanti.net/blog > > > > > -- > Marcus Cavalcanti > 21 9144-5068 > www.marcuscavalcanti.net/blog > > > _______________________________________________ > 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 > > > > > -- > Marcus Cavalcanti > 21 9144-5068 > www.marcuscavalcanti.net/blog > > > > > -- > Marcus Cavalcanti > 21 9144-5068 > www.marcuscavalcanti.net/blog > ------------------------------ > > _______________________________________________ > 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 > > > > > -- > 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 > > -- 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
