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
