Será um prazer ;) Model: http://rafb.net/p/lvUQZn85.html Controller: http://rafb.net/p/9xn4qn83.html View: http://rafb.net/p/BmjSN559.html
Tomara que eu não passe vergonha :D ----- Original Message ----- From: bsb infor To: [email protected] Sent: Wednesday, February 11, 2009 10:15 AM Subject: Re: [CodeIgniter] Exemplo MVC boas praticas (Eric Saboia) 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 To: CodeIgniter Brasil 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
_______________________________________________ Lista mailing list [email protected] http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
