Colocar a lógica de apresentação no controlador é uma boa prática em Ruby?

Question

Alguns recomendação [1] sugiro que você use

<%= current_user.welcome_message %>

em vez de

<% if current_user.admin? %>
  <%= current_user.admin_welcome_message %>
<% else %>
  <%= current_user.user_welcome_message %>
<% end %>

Mas o problema é que você deve ter a lógica de decisão em algum lugar no seu código.

O meu entendimento é de colocar a decisão em template é melhor do que controller como fazer o seu controlador mais limpo.É correto?

Há melhor maneira de lidar com isso?

http://robots.thoughtbot.com/post/27572137956/tell-dont-ask

Answer 1

Na minha opinião, se o texto é a única coisa que muda, ela não pertence a um modo de exibição.Se você necessários para a reestruturação da página, que a lógica de apresentação.Este, este é apenas um conjunto de dados a ser diferentes.

Answer 2

Você não é o primeiro a me perguntar isso.Se vistas e controladores deve ter pouca ou nenhuma lógica, e o modelo deve ser de apresentação agnóstica, onde é que a lógica de apresentação pertencem?

Acontece que podemos usar uma técnica de idade chamado decorator pattern.A ideia é envolver o seu modelo de objeto com outra classe que contém a lógica de apresentação.Esta classe de wrapper é chamado a decorator.O decorador abstrai a lógica do seu ponto de vista, embora mantendo os seus modelos isolados a partir de sua apresentação.

Draper é um excelente jóia que ajuda a definir decoradores.

O código de exemplo que você deu, poderia ser resumida assim:

Passar um decorador para o modo de exibição com @user = UserDecorator.new current_user em seu controlador.

Seu decorador pode olhar como abaixo.

class UserDecorator
  decorates :user

  def welcome_message
    if user.admin?
      "Welcome back, boss"
    else
      "Welcome, #{user.first_name}"
    end
  end
end

E sua opinião seria simplesmente conter @user.welcome_message

Observe que o modelo em si não contém a lógica para criar as mensagens.Em vez disso, o decorador envolve o modelo e traduz o modelo de dados em uma forma apresentável.

Espero que isso ajude!

Answer 3

Eu iria usar um helper para isso.Suponha que você tem para traduzir bem-vindo-mensagem, com base em alguma localidade.

No app/helper/user_helper.rb escrever

module UserHelper

  def welcome_message(user)
    if user.admin?
      I18n.t("admin_welcome_message", :name => user.name)
    else
      I18n.t("user_welcome_message", :name => user.name)
    end
  end 

end

e na sua opinião, em seguida, você pode apenas escrever

<%= welcome_message(user) %>

Observe que o decorador/apresentador oferece realmente limpa abordagem orientada a objeto, mas imho usando um auxiliar é muito mais simples e suficientes.

Answer 4

Não, você não quer qualquer condicionais na classe de usuário nem o controlador.A ponto de que o exemplo no post do blog é fazer referência ao polimorfismo, apenas a boa e velha moda de design OO.

# in application_controller for example
def current_user
  if signed_in?
    User.find(session[:user_id])
  else
    Guest.new
  end  
end

#app/models/user.rb
class User
   def welcome_message
     "hello #{name}"
   end
end

#app/models/guest.rb
class Guest
  def welcome_message
    "welcome newcomer"
  end
end

...você começa a idéia.

Apenas, em vez de causar desordem seu modelo com apresentação somente de métodos, criar um decorator que atua como apresentador:

require 'delegate'
class UserPresenter < SimpleDelegator
  def welcome_message
    "hello #{name}"
  end
end

E agora current_user fica assim:

# application_controller
def current_user
  if signed_in?
    UserPresenter.new(User.find(session[:user_id]))
  else
    Guest.new
  end
end

Answer 5

Decore o modelo de usuário e adicionar o welcome_message diretamente para ela.Sim, isso pode envolver algum tipo de instrução condicional em algum ponto.

http://robots.thoughtbot.com/post/14825364877/evaluating-alternative-decorator-implementations-in

Answer 6

Eu acho que você deve assistir os railscasts episódio em que os Apresentadores para a resposta.

Answer 7

A lógica, o modo de exibição é difícil de manter, devemos colocar a lógica de negócio no modelo e toda a lógica da view em ajudantes.

Se você deseja que o seu código para ser Orientada por objectos de moda, fazer uso de Decoradores (orientada a objeto, forma de ajudantes)

Melhor Exemplo : https://github.com/jcasimir/draper

Answer 8

Coloque o código a definir current_user.welcome_message em _app/helpers/application_helper.rb_, em seguida, será acessível por qualquer view renderizada com o aplicação layout.

Outra opção é definir um personalizado módulo auxiliar, o que não é necessariamente associado com um determinado modo de exibição ou o controlador (Veja o vídeo no link abaixo), e include ele nos módulos de o ver/controladores você deseja ter essa funcionalidade.

Isso não é algo que é preto e branco.Mas, pelo que você descreveu parece que este é o código que é intrusiva para ficar em sua application_controller.rb e não é de código com a funcionalidade, o que justifica seu próprio controlador, o mais eficaz e eficiente opção pode ser a de criar um personalizado de um módulo auxiliar e inclui-lo no ajudantes que você gostaria de ter essa funcionalidade.O que disse, isto é, em última análise, um julgamento que o designer do aplicativo (por exemplo, você) precisa decidir.

Aqui é um bom artigo descrevendo auxiliar de módulos de Maio, 2011

Aqui é um RailsCast destaques personalizado auxiliar de módulos (por exemplo,como costume em módulos não necessariamente associadas a um determinado controlador ou vista).Curto e doce, e ao ponto.

Answer 9

Você pode definir o método auxiliar para que outras coisas.Eu não acho que é uma boa Idéia fazer um bem-vindo frases em um modelo, mas no controlador também.Mas você deve tentar fazer com que você vistas limpeza de código, e se você pode usar programas auxiliares para que, em seguida, você deve.

Answer 10

Uma boa prática seria a de ter real View instâncias.Trilhos paródia de MVP (há uma diferença, procure-a), infelizmente, parece fingir que pontos de vista são modelos.O que é errado.

Pontos de vista deveriam conter a lógica de apresentação em MVC MVC-padrões inspirados.Eles também são suposto para manipular vários modelos e fazer a decisão sobre quais modelos para empregar para representar o estado e informações da camada de modelo (sim, o modelo é uma camada não um ORM exemplo).

Então, para responder a pergunta: lógica de apresentação tem lugar em controladores.