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
