Modelo, visualização, controlador e auxiliar do Rails:o que vai para onde?

StackOverflow https://stackoverflow.com/questions/60658

Pergunta

No desenvolvimento Ruby on Rails (ou MVC em geral), que regra rápida devo seguir sobre onde colocar a lógica.

Por favor responda afirmativamente - Com Coloque isso aqui, em vez de Não coloque isso aí.

Foi útil?

Solução

MVC

Controlador:Coloque aqui o código que tem a ver com descobrir o que um usuário deseja e decidir o que dar a ele, descobrir se ele está logado, se deve ver determinados dados, etc.No final, o controlador analisa as solicitações e decide quais dados (modelos) mostrar e quais visualizações renderizar.Se você estiver em dúvida se o código deve entrar no controlador, provavelmente não deveria.Mantenha seus controladores magrelo.

Visualizar:A view deve conter apenas o código mínimo para exibir seus dados (Modelo), não deve fazer muitos processamentos ou cálculos, deve exibir dados calculados (ou resumidos) pelo Modelo, ou gerados a partir do Controlador.Se a sua View realmente precisa fazer um processamento que não pode ser feito pelo Model ou Controller, coloque o código em um Helper.Muito código Ruby em uma View dificulta a leitura da marcação das páginas.

Modelo:Seu modelo deve estar onde todos o seu código relacionado aos seus dados (as entidades que compõem o seu site, por exemploUsuários, postagens, contas, amigos etc.) vidas.Se o código precisar salvar, atualizar ou resumir dados relacionados às suas entidades, coloque-o aqui.Ele será reutilizável em suas visualizações e controladores.

Outras dicas

Para adicionar à resposta de pauliephonic:

Ajudante:funções para facilitar a criação da visualização.Por exemplo, se você está sempre iterando em uma lista de widgets para exibir seus preços, coloque-o em um auxiliar (junto com um parcial para a exibição real).Ou se você tiver um pedaço de RJS que não deseja atrapalhar a visualização, coloque-o em um auxiliar.

O padrão MVC realmente se preocupa apenas com a UI e nada mais.Você não deve colocar nenhuma lógica de negócios complexa no controlador, pois ele controla a visualização, mas não a lógica.O Controller deve se preocupar em selecionar a visão adequada e delegar coisas mais complexas ao modelo de domínio (Model) ou à camada de negócio.

O Domain Driven Design tem um conceito de serviços que é um lugar onde você coloca a lógica que precisa orquestrar vários tipos de objetos, o que geralmente significa lógica que não pertence naturalmente a uma classe Model.

Geralmente penso na camada de serviço como a API dos meus aplicativos.Minhas camadas de serviços geralmente mapeiam de perto os requisitos do aplicativo que estou criando, portanto, a camada de serviço atua como uma simplificação das interações mais complexas encontradas nos níveis mais baixos do meu aplicativo, ou seja,você poderia atingir o mesmo objetivo ignorando as camadas de serviço, mas teria que usar muito mais alavancas para fazê-lo funcionar.

Observe que não estou falando sobre Rails aqui, estou falando de um estilo arquitetônico geral que aborda seu problema específico.

Explicações perfeitas já aqui, uma frase muito simples como conclusão e fácil de lembrar:

Precisamos de modelos SMART, controladores THIN e visualizações DUMB.

http://c2.com/cgi/wiki?ModelViewController

O jeito do Rails é ter controladores magros e modelos gordos.

Coloque coisas relacionadas ao controle de autorização/acesso no controlador.

Os modelos têm tudo a ver com seus dados.Validação, Relacionamentos, CRUD, Lógica de Negócios

As visualizações servem para mostrar seus dados.Exibir e obter apenas entrada.

Os controladores controlam quais dados vão do seu modelo para a sua visualização (e qual visualização) e da sua visualização para o seu modelo.Os controladores também podem existir sem modelos.

Gosto de pensar no controlador como um segurança / recepcionista que direciona o cliente (solicitação) ao balcão apropriado, onde você faz uma pergunta ao caixa (visualização).O caixa (visualização) então vai e obtém a resposta de um gerente (modelo), que você nunca vê.Você faz a solicitação e depois volta para o segurança/recepcionista (controlador) e espera até ser direcionado para outro caixa (visualização) que lhe dá a resposta que o gerente (modelo) disse a eles em resposta à pergunta do outro caixa (visualização) .

Da mesma forma, se você quiser dizer algo ao caixa (ver) algo, então basicamente a mesma coisa acontece, exceto que o segundo caixa lhe dirá se o gerente aceitou suas informações.Também é possível que o segurança/recepcionista (controlador) tenha lhe dito para fazer uma caminhada, uma vez que você não estava autorizado a passar essa informação ao gerente.

Então, para estender a metáfora, no meu mundo estereotipado e irreal, os caixas (opiniões) são bonitos, mas de cabeça vazia e muitas vezes acreditam em qualquer coisa que você lhes diz, os seguranças/recepcionistas são minimamente educados, mas não têm muito conhecimento, mas sabem onde as pessoas devem e não deveria ir e os gerentes são realmente feios e mesquinhos, mas sabem tudo e podem dizer o que é verdade e o que não é.

Uma coisa que ajuda a separar corretamente é evitar o antipadrão "passar variáveis ​​locais do controlador para visualizar".Em vez disso:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  def show
    @foo = Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...

Tente movê-lo para um getter que esteja disponível como método auxiliar:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  helper_method :foo

  def show
  end

  protected

  def foo
    @foo ||= Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...

Isso torna mais fácil modificar o que é colocado em "@foo" e como ele é usado.Aumenta a separação entre o controlador e a visualização sem torná-los mais complicados.

Bem, isso depende do que a lógica tem que lidar ...

Freqüentemente, faz sentido incluir mais coisas em seus modelos, deixando os controladores pequenos.Isso garante que essa lógica possa ser facilmente usada de qualquer lugar onde você precise acessar os dados que seu modelo representa.As visualizações quase não devem conter lógica.Então, realmente, em geral, você deve se esforçar para não se repetir.

Além disso, uma rápida pesquisa no Google revela mais alguns exemplos concretos do que vai para onde.

Modelo:requisitos de validação, relacionamentos de dados, métodos de criação, métodos de atualização, métodos de destruição, métodos de localização (observe que você não deve ter apenas as versões genéricas desses métodos, mas se há algo que você faz muito, como encontrar pessoas ruivas por sobrenome, então você deve extrair essa lógica para que tudo o que você precise fazer seja chamar find_redH_by_name("smith") ou algo parecido)

Visualizar:Tudo isso deve ser uma questão de formatação de dados, não de processamento de dados.

Controlador:É aqui que vai o processamento de dados.Da internet:“O objetivo do controlador é responder à ação solicitada pelo usuário, pegar quaisquer parâmetros que o usuário tenha definido, processar os dados, interagir com o modelo e, em seguida, passar os dados solicitados, na forma final, para a visualização.”

Espero que ajude.

Em termos simples, geralmente,Modelos terá todos os códigos relacionados à(s) tabela(s), seus relacionamentos simples ou complexos (pense neles como consultas sql envolvendo múltiplas tabelas), manipulação dos dados/variáveis ​​para chegar a um resultado utilizando a lógica de negócio.

Controladores terá códigos/indicadores para os modelos relevantes para o trabalho solicitado.

Visualizações aceitará a entrada/interação do usuário e exibirá a resposta resultante.

Qualquer grande desvio destes irá sobrecarregar essa parte e o desempenho geral do aplicativo poderá ser afetado.

Testando, testando...Coloque o máximo de lógica possível no modelo e então você poderá testá-lo corretamente.Os testes unitários testam os dados e a forma como eles são formados testando o modelo, e os testes funcionais testam a forma como eles são roteados ou controlados testando os controladores, portanto, você não pode testar a integridade dos dados a menos que esteja em o modelo.

j

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top