Controller magro, modelo gordo

http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model

O pessoal estava discutindo isso ontem na lista do rails-br e é um tópico muito interessante.

De primeira, a gente tende a colocar lógica demais no controller (na view, às vezes). Depois que “cai a ficha”, vc começa a usar o controller só como “cola” entre os models, e muito pouco, se possível.

Lembro que no evento da TempoReal teve gente que saiu com a impressão que o Rails era muito procedural e que o model era apenas uma monte de Data Transfer Objects para fazer interface com o banco de dados. Esse tópico aí em cima exemplifica bem o que deveria de fato acontecer.

Em um dos projetos que estamos envolvidos, foi bem assim. É interessante ver como a gente foi deixando os controllers cada vez mais magros conforme o tempo foi passando.

Mas por outro lado. Dependendo do sistema, não acho que controllers gordos cheguem a ser um problema. Ou seriam sempre?

Vou ler o link que você citou.

Mas de primeira…

Regras de negócio deveriam se implementadas no model. Assim não teriamos fantoches, ou simples “data transfers”, e sim, objetos com responsabilidades uteis no sistema. Verdadeiras entidades no nosso negócio.

E regras de navegação, inevitavelmente, creio eu, devem ficar no controller.

Por muito tempo trabalhei no esquema “Service & Domain”. Ou seja, um serviço que manipula um domain do jeito que bem entende. Mas sinceramente, não acho o melhor design.

Porém… é o que “arquitetos” muitas vezes acabam impondo.

Minha palavra final: REGRAS DE NEGÓCIO NO DOMAIN, NAVEGAÇÃO NO CONTROLER, e ponto final. :)

(Gostei da thread)

Abraço galera!

(Quando puder visite: http://aartededesenvolversoftware.blogspot.com)

Uma das coisas que o REST acaba forçando são ações bem pequenas, com o código absolutamente necessário para executar uma coisa e passar adiante. Eu ainda estou me acostumando com isso porque a tendência é fazer todos os passos de uma vez só. Por exemplo, eu sempre fazia o new, create, update e edit em um só método porque o reuso de código é grande. Em REST você sempre quebra, mas o reuso é diferente e os métodos são outros. Ainda estou me decidindo sobre o que é melhor.

mas pelo menos na pouca experiencia que tenho, ajax engorda legal os controllers

Ah, com certeza. :-) Não só os controllers, mas os arquivos que o navegador tem que baixar, os templates a mais, os código para degradação, o resultado das páginas, etc…

Ronaldo, na sua opnião, existe outra forma ? de usar ajax com rails.

Até onde eu sei, não. O máximo que dá para fazer é tentar usar só os arquivos necessários e usar algo como o UJS4Rails para reduzir o lixo nas páginas geradas. Mas, tomando o Google como exemplo, o Gmail demora um bocado para carregar. Se eles não conseguem reduzir o JavaScript, quem somos nós :-) De qualquer forma, com novos interpretadores/compiladores JavaScript chegando, não vai ser tão ruim a longo prazo.

e quando a aplicacao tende pro lado mais interativo, a coisa fica pior.

No meu projetinho eu tenho algumas coisas em flash (galeria de imagens e mp3 player) que ficariam inviaveis ou mediocres com ajax. A integracao com o flash eh via xml. Porem eu tive que usar ao mesmo tempo ajax para atualizar o flash em algumas situacoes. Esse eh o pior controlador da minha aplicacao. Pensei em separar em dois controladores mas acho que ficaria pior pq algumas coisas eu teria de repetir ou subir para o application

Concordo que um m3p player provavelmente seria inviável em Ajax. Mas as melhores galerias de imagens que eu já voi foram feitas em Ajax e não em Flash. E quanto à interatividade, depois que coisas como o Oddpost (hoje Yahoo! Mail) e a própria YUL, 90% do que antes precisava de Flash pode ser feito mais facilmente com Ajax (e com menos problemas de sincronia). É claro que o Flash está melhorando e vai tentar para ajudar em coisas ainda mais complexas (3D, som, etc), mas o Ajax de hoje não é seu Ajax da mamãe. :-P

Ronaldo, cita aê algumas das galerias de imagens Ajax que você disse…

Mesmo que vc use um framework como o Dojo ou alguma yui não tem como fujir da demora, toda a definição de RIA parte desse principio, 1 vez carregada a segunda vez é mais rapida, tudo roda no cliente, o grande problema do javascript/ajax que nem sempre ele faz cache, já flash/flex/open-laszlo já faz cache.

Aplicações RIA é assim aplicação bonita controle gordo, então podemos chamar de um gordinho botininho.

Meus controllers tem engordado consideravelmente, até cheguei a falar com o Ronie sobre isso, eu ainda uso Rails como Always Keep It Simple Stupid, não sei até agora se fazer isso melhora ou piora o desempenho, Ronaldo ou o Ronie podia compartilhar com a gente sobre a performace de dividir e de não dividir, ou se é somente mais um modo de manter as coisas nos seus devidos lugares e boas técnicas de programação.

Bom…

O ponto não é realmente desempenho.

Desempenho, com certeza não vai ser afetado por controller inchado ou model inchado. O que vai gargalar sua aplicação é muito difícil de prever, melhor medir (o Rails tem logs ótimos pra isso, nem precisa “profiling”). E tenho certeza que um dos primeiros candidatos vai ser o
banco de dados. ;)

O ponto da coisa é o fato de que controladores gordos fazem com que sua aplicação seja menos Orientada a Objeto, o que, em teoria, significa que ela é mais difícil de dar manutenção.

Até minha experiência vai, realmente, qto mais OO mais fácil de dar manutenção e evoluir. Mas o Rails gera uma situação estranha, onde o controlador é responsável por apenas uma ação, e é uma ação sobre apenas um objeto (CRUD em cima do objeto User, ou CRUD em cima do objeto Post). Então, não sei ainda no Rails o quanto deixar as coisas no controller é realmente ruim.

Pode ser “mau estilo”, mas “prejudicial” são outros quinhentos.

E realmente eu concordo, Ajax tende a engordar um pouco os controllers, mas se vc transferir toda a lógica da action dele pro model, não deveria engordar tanto.

No final, parece que controller bons são controllers “diabéticos” :D

A minha curva de aprendizado pelo Rails, passou de controllers com obesidade mórbida para e views com muito ERB, até o uso extremo de Unit testes antes de escrever qq controlador.

Estou migrando a última aplicação não-Rails da empresa e fazem uns vinte dias que não criei um controller

Este processo atual é bem diferente do que vinha fazendo, pois criava um ou dois modelos e partia para os controladores e views

Desta forma ao qual estou fazendo, defini as prioridades básicas para colocar o sistema no ar. e parti para os models. Neste processo acabei inutilizando alguns modelos que acahva essencial, assim como acabei criando outros tantos, inclusive alguns sem persistência de dados que nem imaginava no projeto.

O fato é que agora eu vou começar a criar os controladores de um sistema inteiramente pronto e arduamente testado quanto a sua lógica.

Em sistemas anteriores tenho métodos em controladores com mais de 10 linhas, o que é muito difícil para dar manutenção e criar lógicas novas.

Não estou me preocupando tanto com a reutilização de código nos controller, mas sim em deixar seus métodos bem enxutos, algo com no máximo 5 linhas em métodos grandes. Mais do que isso já é bom em pensar em transferir parte da lógica pro model e repensar sua utilização.

Uma coisa que é indispensável para engordar os models é a utilização de Unit Tests, é impossível eu ter feito toda a lógica do sistema sem ter escrito tantas linhas de testes e baseado nestes testes, vou poder escrever controllers bem mais magros, parece que é um cliclo, pois antes usava os próprios controllers para testar a lógica dos modelos

Portanto, cheguei a conclusão que para ter uma aplicação mais legível e maleável é necessário começar do começo e o começo são os models, que dependem integralmente dos testes. Depois de tudo modelado testado e funcionando os controller saem de maneira natural, otimizada e guardamos as nossas ‘energias’ para pensar única e exclusivamente em como o sistema deve ser apresentado ao usuário.

Pra vcs terem uma idéia ai vai o meu rake stats, sendo que comecei a escrever os controller ontém depois de um mês só nos models e tests:

——————————————-———-————-————-——-———-

| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |

——————————————-———-————-————-——-———-

| Helpers              |    33 |    28 |       0 |       3 |   0 |     7 |

| Controllers          |   175 |   136 |       8 |      25 |   3 |     3 |

| Components           |     0 |     0 |       0 |       0 |   0 |     0 |

|   Functional tests   |   196 |   141 |      14 |      28 |   2 |     3 |

| Models               |  1101 |   391 |      27 |      48 |   1 |     6 |

|   Unit tests         |   683 |   600 |      12 |      54 |   4 |     9 |

| Libraries            |    84 |    65 |       0 |      17 |   0 |     1 |

|   Integration tests  |     0 |     0 |       0 |       0 |   0 |     0 |

——————————————-———-————-————-——-———-

| Total                |  2272 |  1361 |      61 |     175 |   2 |     5 |

——————————————-———-————-————-——-———-

  Code LOC: 620     Test LOC: 741     Code to Test Ratio: 1:1.2

Um exemplo interessante de site de imagens com ajax foi esse site feito um amigo meu (em RoR claro) http://www.drausiotuzzolo.com.br/ . Vale a pena entrar no portifolio pra ver o “pra frente” “pra trás” em ajax.

Arthur, o fluxiom, embora não seja propriamente uma galeria de imagens, mas um gerenciador de imagens, é um excelente exemplo tanto de Rails quanto de Ajax. Se você procurar na Web, vai achar um outro tanto em linguagens que vão de PHP a .NET.

para imagens podem utilizar o lightbox
ou o
thickbox

tem um outro que eu achei ontem, que se chama gullery. muito legalzinho e usa ajax. além disso, tem filminho :-)