Olá Eric Saboia, estou acompanhando esta lista e achei muitissimo interessante seu model, gostaria de lhe pedir que postasse aqui as 3 camadas, desta forma acho que fica facil pra qualquer pessoa entender.
Se eu estiver abusando favor desculpar. Abraço a todos. 2009/2/11 <[email protected]> > Enviar submissões para a lista de discussão Lista para > [email protected] > > Para se cadastrar ou descadastrar via WWW, visite o endereço > http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br > ou, via email, envie uma mensagem com a palavra 'help' no assunto ou > corpo da mensagem para > [email protected] > > Você poderá entrar em contato com a pessoa que gerencia a lista pelo > endereço > [email protected] > > Quando responder, por favor edite sua linha Assunto assim ela será > mais específica que "Re: Contents of Lista digest..." > > Tópicos de Hoje: > > 1. Re: Exemplo MVC (boas práticas) (Eric Saboia (Fortes Informatica)) > > > ---------- Mensagem encaminhada ---------- > From: "Eric Saboia \(Fortes Informatica\)" <[email protected]> > To: "CodeIgniter Brasil" <[email protected]> > Date: Wed, 11 Feb 2009 09:07:36 -0300 > Subject: Re: [CodeIgniter] Exemplo MVC (boas práticas) > Vinicius, > 5 camadas no DDD? até onde eu sabia eram 4, e que pra mim na verdade acabam > sendo as 3 do MVC, ele só divide o Model em duas camadas, pra separar o que > realmente pertence a um dominio e o que é utilizado (requerido e etc) por > esse domínio. > > O livro que indico sobre DDD é: Domain-Driven DESIGN por Eric Evans, que é > o criador da "pattern". > > Quanto a um Model pra cada tabela, isso não existe.. na verdade o que você > tem pra cada tabela é um objeto persistente, a tal classe que tem atributos > iguais as colunas de uma tabela (no caso o CI não implementa isso > nativamente, você pode procurar algo sobre ORM se tiver interesse), mas um > modelo pode conter vários métodos utilizando mais de uma tabela (desde que > sejam do mesmo domínio) > > Aproveitando o que acabei de falar e respondendo a outra dúvida, de como > deve ser a lógica quando precisamos de um registro dentro do outro (Como > recuperar a lista de usuários e seus emails), eu faço assim: > > > > function > listarEvento($data=false) > { > // Percorre os meses > $meses = $this->listarMes($data); > > foreach ($meses as $mesRow) { > $retorno[$i]['mes'] = $mesesArray[$mesRow['mes']]; > // Percorre os eventos deste mes > $eventos = $this->listarMesEvento($mesRow['mes'], date('Y'), $data > ); > $retorno[$i]['eventos'] = $eventos; > > $i++; > } > > return $retorno; > } > > Tanto o método listarEvento, quanto o método listarMes, quanto o método > listarMesEvento estão no mesmo modelo. Assim, no listarEvento monto um > objeto contendo todos os meses e dentro de cada mês um objeto contendo todos > os eventos deste mes. > > Dentro do controller simplesmente chamo $this->modelo->listarEvento(); e já > tenho tudo mastigado pra percorrer na view. > > > Ah, por favor fiquem a vontade pra criticar qualquer coisa que falei... > estou aqui aprendendo sobre o assunto tanto quanto vocês! :D > > ----- Original Message ----- > *From:* Ricardo Valfreixo <[email protected]> > *To:* CodeIgniter Brasil <[email protected]> > *Sent:* Tuesday, February 10, 2009 9:29 PM > *Subject:* Re: [CodeIgniter] Exemplo MVC (boas práticas) > > Ola a todos, > > metendo a minha colher. > > O Service Layer começou a ser usado essencialmente por causa dos > interfaces. Assisti de muito perto uma evolução normal de MCV "tradicional" > para uma arquitectura de 4 tiers. A verdade é que para equipas grandes se > torna a forma mais simples de descentralizar trabalho. > > Nesse projecto, tinha um génio das bases de dados que se encarregava de > todos os models e optimização dos bancos de dados. Havia um javascript > wizard que tratava de todos os interfaces. E dois developers que tratavam do > service layer onde o grosso da acção se passava. Os controladores > funcionavam como "policias de transito" que apenas redireccionava > processamento e decidia qual o pedaço de software seguinte a ser chamado. > > Em especial porque havia alguns pedaços do sistema que eram sistemas REST e > webservices. Para isto, o service layer é perfeito. > > Agora, muito sinceramente, para o site pequeno e "normal" os 3 tiers chegam > e sobram. > > Mas isso são os meus dois tostões :) > > // Zen > > > > 2009/2/10 Marcus Cavalcanti <[email protected]> > >> E acho que por ultimo pode deixar esse aqui: >> >> http://www.submarino.com.br/produto/9/373407?franq=102414 >> >> >> >> >> >> 2009/2/10 Marcus Cavalcanti <[email protected]> >> >>> os livros são meios caros,mas vale.. >>> >>> mas tem um site que tem pdf de livros, para quem curtir: >>> http://www.flazx.com/ >>> >>> >>> 2009/2/10 Marcus Cavalcanti <[email protected]> >>> >>>> É isso, pensa que no controller não deve conhecer as regras da sua >>>> aplicação, ele apenas faz chamdas, controla fluxo, popula objetos, essas >>>> coisas, mas ele não deve conhecer regras .. >>>> >>>> Livros: >>>> >>>> http://www.submarino.com.br/produto/9/343713/domain-driven+design >>>> >>>> http://www.submarino.com.br/produto/1/1348031/padroes+de+arquitetura+de+aplicacoes+corporativas >>>> >>>> http://www.submarino.com.br/produto/1/242126/refatoracao:+aperfeicoando+o+projeto+de+codigo+existente >>>> >>>> >>>> 2009/2/10 Vinicius Cruz <[email protected]> >>>> >>>>> Fala, Marcus! >>>>> Sobre DDD, tens algum livro ou apostila para indicar? >>>>> >>>>> O que me preocupou com tudo isso é justamente o que citastes. Estou >>>>> vendo além, uma nova abordagem. E, cada mês que passa, o sistema da >>>>> empresa >>>>> tem crescido consideravelmente. E, do jeito que as coisas estão indo, a >>>>> escalabilidade estava em baixa. Ou seja, daqui a um tempo, eu (ou outro >>>>> louco que assumisse o comando) iria se ver doido pra deixar tudo em ordem. >>>>> >>>>> Dai a necessidade de eu entender melhor essa abordagem, analisar as >>>>> entidades, e refatorar, na medida do possivel, o sistema nesse "novo >>>>> conceito". >>>>> >>>>> A mosta tá virando um bicho, eu ainda estou com o mata-mosca em mãos. >>>>> =D >>>>> >>>>> Em relação ao exemplo, minha dúvida é se o code deve estar no >>>>> controller, ou no model, já que o mesmo é responsável pela regra de >>>>> negócio. >>>>> Estive lendo um pouco de ruby on rails, e eles tem por lema deixar o model >>>>> gordo e o controller magro, não é isso? >>>>> >>>>> Vinicius >>>>> >>>>> 2009/2/10 Marcus Cavalcanti <[email protected]> >>>>> >>>>> Fala Vinicus.. DDD é um pouco sobre do que estamos tentando falar, se >>>>>> aprofunde que vale a pena, cada vez que vc se aprofundar, mais vai >>>>>> perceber >>>>>> que sabia menos das coisas hehe isso é normal, por isso as vezes a >>>>>> ignorância uma dádiva, mas em outros casos não hehe >>>>>> >>>>>> Mas vamos lá, então, isso é uma questão bem conceitual mesmo... não é >>>>>> que o CI está errado, acho que ele apenas não dá um suporte NATIVO para >>>>>> aplicações mais complexas, mas nada que você possa extendê-lo, como eu >>>>>> faço >>>>>> por exemplo no caso do services, sacou? Na verdade ele implementa o MVC >>>>>> certo, pois ele separa as coisas, agora como as pessoas fazem o seu uso, >>>>>> aí >>>>>> é outra coisa.. uma coisa que eu acho importante citar é que nesse caso >>>>>> não >>>>>> existe o certo e o errado e a verdade e a mentira, o que existe é uma >>>>>> preocupação para quando o buraco ficar mais embaixo.. se você faz da >>>>>> forma X >>>>>> e te atende muito bem, vc não tem problemas, consegue dar manutenção, >>>>>> extender e etc, ok ótimo, te atende, para que você vai mudar? Agora se >>>>>> você >>>>>> começar a perceber ao conhecer uma nova abordagem que o que você usava >>>>>> pode >>>>>> ser melhorado, é bom vc começar a pensar nisso, o que eu quero dizer é >>>>>> "Não >>>>>> tente matar uma mosca com um tiro do canhão". >>>>>> >>>>>> A gente tá falando de aplicações enterprise, ou seja, aplicações com >>>>>> um certo tamanho, onde é importante você deixar as coisas menos acopladas >>>>>> possíveis e mais coesas também. Por exemplo, ActiveRecord, se vc for >>>>>> parar >>>>>> pra pensar na essencia é um anti-pattern, mas em muitos casos ele dá uma >>>>>> agilidade e velocidade de desenvolvimento que fazer o seu uso é muito >>>>>> bom. >>>>>> Da mesma forma que as vezes você usar Activerecord em alguns casos não é >>>>>> bom, é melhor começar a pensar em soluções que implementem um ORM por >>>>>> exemplo. >>>>>> >>>>>> No seu caso de usuários x emails, você poderia pensar da seguinte >>>>>> forma: >>>>>> >>>>>> - É um usuário que conhece um email ou um email que conhece um >>>>>> usuário? >>>>>> - Um email precisa de alguém para ser enviado, esse alguém é um >>>>>> usuário? >>>>>> - Você precisa ter uma entidade para relação email_x_usuario? Eu >>>>>> sinceramente acredito que nao, pq o dominio da sua aplicacao fala de >>>>>> usuario >>>>>> e email e não de uma relação, nesse caso um "select * from >>>>>> email_x_usuario >>>>>> where id_usuario = ?" não resolveria o problema? e onde isso ficaria? >>>>>> acredito que no modelo de usuario, mas depende. >>>>>> >>>>>> Por isso que é importante vc analisar seu cenário, não tem uma receita >>>>>> de bolo feita, cada aplicação tem um contexto e particularidades o >>>>>> importante nesse caso é conhecer as alternativas para ver a que melhor te >>>>>> atende. >>>>>> >>>>>> Engenheria de software é algo ainda recentemente novo, comparo por >>>>>> exemplo a uma engenharia civil por exemplo, portanto ainda é algo que >>>>>> cabem >>>>>> muitas definições, opniões, conceitos, por isso que a parada é estudar >>>>>> mesmo >>>>>> :) >>>>>> >>>>>> 2009/2/10 Newton Wagner <[email protected]> >>>>>> >>>>>>> Adicionando um pouco de sal à dúvida, neste caso pode-se considerar >>>>>>> >>>>>>> que e-mail seria uma entidade fraca, ou seja, ela não existe sem o >>>>>>> usuário. Mas e se for uma entidade forte? Vocês tratariam da mesma >>>>>>> forma? :) >>>>>>> >>>>>>> >>>>>>> 2009/2/10 Vinicius Cruz <[email protected]>: >>>>>>> > Roberto >>>>>>> > faz sentido. Li uma vez no manual, se não me engano, dizendo que >>>>>>> para cada >>>>>>> > tabela deveria ter um model... oO >>>>>>> > Não lembro exatamente onde foi, mas essa discussão está quebrando >>>>>>> vários >>>>>>> > paradigmas (pelo menos pra mim). >>>>>>> > >>>>>>> > Vinicius >>>>>>> > 2009/2/10 Roberto A. Longhi <[email protected]> >>>>>>> >> >>>>>>> >> Salve Vinicius blz ? >>>>>>> >> >>>>>>> >> =] >>>>>>> >> Bom to entrando de gaiato na história, mas tenho algumas duvidas >>>>>>> referente >>>>>>> >> a isso, e vou colocar algumas considerações. >>>>>>> >> >>>>>>> >> No caso que você ilustrou do usuário com vários emails, acredito >>>>>>> que o >>>>>>> >> ideal é deixar a consulta de emails no mesmo model, neste caso o >>>>>>> model de >>>>>>> >> usuário, para evitar carregar outros models. >>>>>>> >> >>>>>>> >> $queryUsuario = $this->Usuariomodel->getLista(); >>>>>>> >> foreach($queryUsuario->result() as $row) >>>>>>> >> { >>>>>>> >> $idusuario = $row->idusuario; >>>>>>> >> $emails[$idusuario] = >>>>>>> $this->Usuariomodel->getEmails($idusuario); >>>>>>> >> } >>>>>>> >> Estou levando para o lado que o model controla todas as >>>>>>> informações >>>>>>> >> relacionados a aquela entidade (no caso o usuário). Mesmo que ela >>>>>>> seja >>>>>>> >> armazenada em outra tabela (nesse caso uma tabela de >>>>>>> emailXusuario. >>>>>>> >> >>>>>>> >> Faz sentido ? >>>>>>> >> >>>>>>> >> Vinicius Cruz escreveu: >>>>>>> >> >>>>>>> >> Ok, Marcus. >>>>>>> >> Esses dias estava dando uma lida sobre DDD. Li algo sobre >>>>>>> arquitetura de 5 >>>>>>> >> camadas, e estou tentando me aprofundar cada vez mais no assunto. >>>>>>> Alias, to >>>>>>> >> indo hoje fazer uma entrevista pra pós de engenharia de software. >>>>>>> Vou meter >>>>>>> >> as caras nos livros!! =D >>>>>>> >> Agora, sempre surge novas duvidas. Por exemplo: uma vez foi >>>>>>> postado na >>>>>>> >> lista, sobre como recuperar a lista de alguma coisa de um usuário. >>>>>>> Por >>>>>>> >> exemplo: um usuário tem vários emails cadastrados, em uma tabela >>>>>>> de >>>>>>> >> relacionamento. Como recuperar a lista de usuários e seus emails? >>>>>>> >> Como eu faço atualmente. No controller: >>>>>>> >> $queryUsuario = $this->Usuariomodel->getLista(); >>>>>>> >> foreach($queryUsuario->result() as $row) >>>>>>> >> { >>>>>>> >> $emails[$row->idusuario] = >>>>>>> >> $this->Emailsmodel->consulta_emails($row->idusuario); >>>>>>> >> } >>>>>>> >> Mas entrei em profunda depressão em saber que o CI não aborda o >>>>>>> MVC como >>>>>>> >> conceituado (ou pelo menos dá margem ao erro). eheheheheh >>>>>>> >> Mas a questão é: tá errado fazer assim? Qual seria uma outra >>>>>>> abordagem? >>>>>>> >> Vinicius >>>>>>> >> 2009/2/10 Djalma Araújo | www.djalmaaraujo.com.br >>>>>>> >> <[email protected]> >>>>>>> >>> >>>>>>> >>> Então, pode crer... >>>>>>> >>> a idéia é apenas o usuário enviar a imagem dele no portfolio e >>>>>>> atualizar >>>>>>> >>> no banco.. essa atualizacao eu utilizo um funcao o model.. >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> _______________________________________________ >>>>>>> >>> 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 >>>>>>> >> >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Roberto Almeida Longhi >>>>>>> >> Programador >>>>>>> >> Contmatic >>>>>>> >> (11) 2942 6700 Ramal 1404 >>>>>>> >> (11) 8599 9022 >>>>>>> >> www.contmatic.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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>> >> >> >> >> -- >> 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 > >
_______________________________________________ Lista mailing list [email protected] http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
