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
