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