В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.
Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.
Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.
Кроме этих методик пригодятся знания по SOLID, ruby style guide, rails conventions, ruby object model, ruby metaprogramming, основным паттернам.
Самый простой совет — используйте хэлперы. С помощью них удобно описывать частые операции:
Хэлпер menu_item отображает элемент меню в зависимости от политик. Можно расширить этот хэлпер, и он будет выделять активный элемент меню.
Хэлпер show_attribute печатает название атрибута и его значение, если значение есть.
Я использую gem simple_form для рендеринга форм. Этот гем берет на себя всю работу по отображению форм. Понятно, что в случае нестандартных дизайнерских форм этот гем не сработает, но для стандартных форм он подходит отлично.
При построении формы я указываю только необходимое: список полей и их тип. Тексты для labels, placeholders, submit подставляются автоматически — достаточно прописать в файле перевода правильные ключи:
Теперь подробнее про свои inputs.
Например, все текстовые формы должны содержать минимум 10 строк:
Это очень простой пример, инпуты могут быть гораздо сложнее. Например, выбор, в какое состояние можно перевести модель (gem state_machines).
Так же SimpleForm позволяет подключать свои билдеры форм:
PunditFormBuilder отвечает за отображение только тех полей, к которым имеет доступ текущий пользователь приложения. Более подробно я расскажу об этом в главе про ACL.
Давайте теперь рассмотрим более специфическую задачу, а именно проектирование http json api. Вот наиболее простые способы:
Все эти способы противоречат принципу единственной ответственности и паттерну MVC. Модель и конроллер не должны заниматься отображением — это обязанность представлений.
Я вижу 2 способа решения:
Т.е. представления — это не только шаблоны и хэлперы, но и другие объекты, занимающиеся представлением данных, например сериалайзеры.
Так мы плавно подошли к следующему подходу: использование презентеров. В rails они используются как дополнение хэлперов.
gem drapper внес путаницу: его разработчики назвали презентеры декораторами. Хотя эти паттерны похожи, они имеют значительное различие: декораторы не изменяют интерфейс. Так же с этим гемом есть много проблем (можно посмотреть на список issues).
Я нашел простой, элегантный и понятный способ, как реализовать презентеры. Ниже я опишу свою реализацию.
Презентер представляет собой объект, который оборачивает модель и делегирует ей методы. В качестве модели может быть любой объект, даже другой декоратор. Базовый класс Delegator включен в стандартную библиотеку.
Кроме модели презентер содежит view_context, который для удобства назван 'h'.
Это self, доступный в helpers и views. Соответственно, в презентерах можно использовать все хэлперы.
Хэлпер present передает объект-презентер в блок или как результат.
Передачу через блок удобно использовать в шаблонах:
Похожий подход можно использовать, если у вас очень сложная логика отображения и хэлпереры не помогают. Или отсутствует объект для отображения. Например, вывод сложных меню или расписаний событий.
В этой части я рассмотрел способы организации логики представлений. В следующей я покажу, как можно организовать логику контроллеров. В последующих — расскажу про модели. А именно: form-objects, services, ACL, query-objects, взаимодействие с различными хранилищами.
Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.
Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.
Кроме этих методик пригодятся знания по SOLID, ruby style guide, rails conventions, ruby object model, ruby metaprogramming, основным паттернам.
Helpers
Самый простой совет — используйте хэлперы. С помощью них удобно описывать частые операции:
module ApplicationHelper
def menu_item(model, action, name, url, link_options = {})
return unless policy(model).send "#{action}?"
content_tag :li do
link_to name, url, link_options
end
end
end
# _nav.haml
= menu_item current_user, :show, t(:show_profile), user_path(current_user)
= menu_item current_user, :edit, t(:edit_profile), edit_user_path(current_user)
Хэлпер menu_item отображает элемент меню в зависимости от политик. Можно расширить этот хэлпер, и он будет выделять активный элемент меню.
module ApplicationHelper
def han(model, attribute)
model.to_s.classify.constantize.human_attribute_name(attribute)
end
def show_attribute(model, attribute)
value = model.send(attribute)
return if value.blank?
[
content_tag(:dt, han(model.model_name, attribute)),
content_tag(:dd, value)
].join.html_safe
end
end
# show.haml
= show_attribute user_presenter, :name
= show_attribute user_presenter, :role_text
= show_attribute user_presenter, :profile_image
Хэлпер show_attribute печатает название атрибута и его значение, если значение есть.
Form templates
= simple_form_for @user, builder: PunditFormBuilder do |f|
= f.input :name
= f.input :contacts, as: :big_textarea
# some other inputs
= f.button :submit
Я использую gem simple_form для рендеринга форм. Этот гем берет на себя всю работу по отображению форм. Понятно, что в случае нестандартных дизайнерских форм этот гем не сработает, но для стандартных форм он подходит отлично.
При построении формы я указываю только необходимое: список полей и их тип. Тексты для labels, placeholders, submit подставляются автоматически — достаточно прописать в файле перевода правильные ключи:
ru:
attributes:
created_at: Создано
activerecord:
attributes:
user:
name: Имя
helpers:
submit:
create: Сохранить
Теперь подробнее про свои inputs.
Например, все текстовые формы должны содержать минимум 10 строк:
class BigTextareaInput < SimpleForm::Inputs::TextInput
def input_html_options
{ rows: 10 }
end
end
Это очень простой пример, инпуты могут быть гораздо сложнее. Например, выбор, в какое состояние можно перевести модель (gem state_machines).
Так же SimpleForm позволяет подключать свои билдеры форм:
class PunditFormBuilder < SimpleForm::FormBuilder
def input(attribute_name, options = {}, &block)
return unless show_attribute? attribute_name
super(attribute_name, options, &block)
end
def show_attribute?(attr_name)
# some code
end
end
= simple_form_for @user, builder: PunditFormBuilder do |f|
PunditFormBuilder отвечает за отображение только тех полей, к которым имеет доступ текущий пользователь приложения. Более подробно я расскажу об этом в главе про ACL.
Serializers
Давайте теперь рассмотрим более специфическую задачу, а именно проектирование http json api. Вот наиболее простые способы:
- метод
Model#to_json - метод конроллера serialize_model
Все эти способы противоречат принципу единственной ответственности и паттерну MVC. Модель и конроллер не должны заниматься отображением — это обязанность представлений.
Я вижу 2 способа решения:
- шаблоны jbuilder
- serializers, причем как одноименный gem, так и просто объекты-сериализаторы (сериалайзеры?)
class CommentSerializer < ActiveModel::Serializer
attributes :name, :body
belongs_to :post
end
Т.е. представления — это не только шаблоны и хэлперы, но и другие объекты, занимающиеся представлением данных, например сериалайзеры.
Presenters
Так мы плавно подошли к следующему подходу: использование презентеров. В rails они используются как дополнение хэлперов.
gem drapper внес путаницу: его разработчики назвали презентеры декораторами. Хотя эти паттерны похожи, они имеют значительное различие: декораторы не изменяют интерфейс. Так же с этим гемом есть много проблем (можно посмотреть на список issues).
Я нашел простой, элегантный и понятный способ, как реализовать презентеры. Ниже я опишу свою реализацию.
# app/presenters/base_presenter.rb
class BasePresenter < Delegator
attr_reader :model, :h
alias_method :__getobj__, :model
def initialize(model, view_context)
@model = model
@h = view_context
end
def inspect
"#<#{self.class} model: #{model.inspect}>"
end
end
Презентер представляет собой объект, который оборачивает модель и делегирует ей методы. В качестве модели может быть любой объект, даже другой декоратор. Базовый класс Delegator включен в стандартную библиотеку.
Кроме модели презентер содежит view_context, который для удобства назван 'h'.
Это self, доступный в helpers и views. Соответственно, в презентерах можно использовать все хэлперы.
# app/presenters/task_presenter.rb
class TaskPresenter < BasePresenter
def to_link
h.link_to model.to_s, model
end
def description
h.markdown model.description
end
# оборачиваем связь
def users
model.users.map { |user| h.present user }
end
end
# app/helpers/application_helper.rb
def present(model)
return if model.blank?
klass = "#{model.class}Presenter".constantize
presenter = klass.new(model, self)
yield(presenter) if block_given?
presenter
end
Хэлпер present передает объект-презентер в блок или как результат.
Передачу через блок удобно использовать в шаблонах:
# app/views/web/tasks/index.haml
- @tasks.each do |task|
%tr
- present task do |task_presenter|
%td= task_presenter.id
%td= task_presenter.to_link
%td= task_presenter.project
Похожий подход можно использовать, если у вас очень сложная логика отображения и хэлпереры не помогают. Или отсутствует объект для отображения. Например, вывод сложных меню или расписаний событий.
class MenuRenderer
attr_reader :h
def initialize(view_context)
@h = view_context
end
def render
some_hard_logic
end
private
def some_hard_logic
h.link_to '', ''
end
end
В этой части я рассмотрел способы организации логики представлений. В следующей я покажу, как можно организовать логику контроллеров. В последующих — расскажу про модели. А именно: form-objects, services, ACL, query-objects, взаимодействие с различными хранилищами.
