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
