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
_______________________________________________ Lista mailing list [email protected] http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
