7 Шаблоны проектирования для рефакторинга компонентов MVC в Rails

 class ArticlesController < ApplicationController def index @articles = Article .accessible_by(current_ability) .popular_with_video_type end end 

Это намного лучше, но теперь возникают новые проблемы. Нам нужно создать области для каждого условия запроса, которое мы хотим инкапсулировать, увеличивая Модель с различными комбинациями областей действия для разных вариантов использования. Другая проблема заключается в том, что области не могут повторно использоваться в разных моделях, что означает, что вы не можете просто использовать область действия из класса Article для запроса класса Attachment. Мы также нарушаем принцип единой ответственности, отбрасывая все связанные с запросами обязанности в класс Article. Решением этих проблем является использование объекта Query.

 class PopularVideoQuery def call(relation) relation .where(type: :video) .where('view_count > ?', 100) end end class ArticlesController < ApplicationController def index relation = Article.accessible_by(current_ability) @articles = PopularVideoQuery.new.call(relation) end end 

Вау, это многоразово! Теперь мы можем использовать этот класс для запроса любых других репозиториев, имеющих похожую схему:

 class Attachment < ActiveRecord::Base # t.string :type # t.integer :view_count end PopularVideoQuery.new.call(Attachment.all).to_sql # "SELECT \"attachments\".* FROM \"attachments\" WHERE \"attachments\".\"type\" = 'video' AND (view_count > 100)" PopularVideoQuery.new.call(Article.all).to_sql # "SELECT \"articles\".* FROM \"articles\" WHERE \"articles\".\"type\" = 'video' AND (view_count > 100)" 

Кроме того, если мы хотим связать их, это просто. Единственное, что мы должны принять во внимание, это то, что метод call должен соответствовать интерфейсам ActiveRecord::Relation :

 class BaseQuery def |(other) ChainedQuery.new do |relation| other.call(call(relation)) end end end class ChainedQuery < BaseQuery def initialize(&block) @block = block end def call(relation) @block.call(relation) end end class WithStatusQuery < BaseQuery def initialize(status) @status = status end def call(relation) relation.where(status: @status) end end query = WithStatusQuery.new(:published) | PopularVideoQuery.new query.call(Article.all).to_sql # "SELECT \"articles\".* FROM \"articles\" WHERE \"articles\".\"status\" = 'published' AND \"articles\".\"type\" = 'video' AND (view_count > 100)" 

Теперь у нас есть многократно используемый класс со всей инкапсулированной логикой запроса, с простым интерфейсом, который легко тестировать.

Просмотр объектов (сериализатор / ведущий)

Объект View позволяет нам получать данные и расчеты, которые необходимы только для отображения представления модели в представлении, такого как HTML-страница для веб-сайта или ответ JSON от конечной точки API, из контроллера и модели.

пример

В представлении происходят различные действия (расчеты). Вид:

• Создает URL изображения из хоста протокола и пути к изображению
• Принимает название статьи и описание; если нет никаких пользовательских значений, он принимает значения по умолчанию
• Объединяет имя и фамилию для отображения полного имени
• Применяет правильное форматирование для даты создания статьи

проблема

Представление содержит слишком много логики вычислений.

 #before refactoring #/app/controllers/articles_controller.rb class ArticlesController < ApplicationController def show @article = Article.find(params[:id]) end end #/app/views/articles/show.html.erb <% content_for :header do %> <title> <%= @article.title_for_head_tag || I18n.t('default_title_for_head') %> </title> <meta name='description' content="<%= @article.description_for_head_tag || I18n.t('default_description_for_head') %>"> <meta property="og:type" content="article"> <meta property="og:title" content="<%= @article.title %>"> <% if @article.description_for_head_tag %> <meta property="og:description" content="<%= @article.description_for_head_tag %>"> <% end %> <% if @article.image %> <meta property="og:image" content="<%= "#{request.protocol}#{request.host_with_port}#{@article.main_image}" %>"> <% end %> <% end %> <% if @article.image %> <%= image_tag @article.image.url %> <% else %> <%= image_tag 'no-image.png'%> <% end %> <h1> <%= @article.title %> </h1> <p> <%= @article.text %> </p> <% if @article.author %> <p> <%= "#{@article.author.first_name} #{@article.author.last_name}" %> </p> <%end%> <p> <%= t('date') %> <%= @article.created_at.strftime("%B %e, %Y")%> </p> 

Чтобы решить эту проблему, мы создаем базовый класс презентатора, а затем создаем ArticlePresenter класса ArticlePresenter . Методы ArticlePresenter возвращают нужные теги с соответствующими вычислениями:

 #/app/controllers/articles_controller.rb class ArticlesController 

Большой! У нас есть представление, которое не содержит никакой логики, связанной с вычислениями, и все компоненты были перемещены в презентатор и могут использоваться в других представлениях следующим образом:

 #/app/views/articles/show.html.erb <% presenter @article do |article_presenter| %> <% content_for :header do %> <%= article_presenter.meta_title %> <%= article_presenter.meta_description %> <%= article_presenter.og_type %> <%= article_presenter.og_title %> <%= article_presenter.og_description %> <%= article_presenter.og_image %> <% end %> <%= article_presenter.image%> <h1> <%= article_presenter.title %> </h1> <p> <%= article_presenter.text %> </p> <%= article_presenter.author_name %> <% end %> 

Объекты политики

Шаблон проектирования объектов политики аналогичен объектам службы, но отвечает за операции чтения, а объекты службы отвечают за операции записи. Объекты политики инкапсулируют сложные бизнес-правила и могут быть легко заменены другими объектами политики с другими правилами. Например, мы можем проверить, может ли гостевой пользователь получить определенные ресурсы, используя гостевой объект политики. Если пользователь является администратором, мы можем легко изменить этот гостевой объект политики на объект политики администратора, который содержит правила администратора.

пример

Перед тем, как пользователь создает проект, Контроллер проверяет, является ли текущий пользователь менеджером, есть ли у него разрешение на создание проекта, не превышает ли число текущих пользовательских проектов максимальное количество, и проверяет наличие блоков при создании проектов. в хранилище ключей / значений Redis.

проблема

• Только Контроллер знает о политиках создания проекта
• Контроллер содержит чрезмерную логику

 class ProjectsController < ApplicationController def create if can_create_project? @project = Project.create!(project_params) render json: @project, status: :created else head :unauthorized end end private def can_create_project? current_user.manager? && current_user.projects.count < Project.max_count && redis.get('projects_creation_blocked') != '1' end def project_params params.require(:project).permit(:name, :description) end def redis Redis.current end end def User < ActiveRecord::Base enum role: [:manager, :employee, :guest] end 

Чтобы сделать контроллер более тонким, мы переместили логику политики в модель. В результате проверка полностью перемещается из контроллера. Но теперь класс User знает о логике класса Redis и Project, и поэтому модель становится толстой.

 def User < ActiveRecord::Base enum role: [:manager, :employee, :guest] def can_create_project? manager? && projects.count < Project.max_count && redis.get('projects_creation_blocked') != '1' end private def redis Redis.current end end class ProjectsController < ApplicationController def create if current_user.can_create_project? @project = Project.create!(project_params) render json: @project, status: :created else head :unauthorized end end private def project_params params.require(:project).permit(:name, :description) end end 

В этом случае мы можем сделать Модель и Контроллер тонкими, переместив эту логику в объект политики:

 class CreateProjectPolicy def initialize(user, redis_client) @user = user @redis_client = redis_client end def allowed? @user.manager? && below_project_limit && !project_creation_blocked end private def below_project_limit @user.projects.count < Project.max_count end def project_creation_blocked @redis_client.get('projects_creation_blocked') == '1' end end class ProjectsController < ApplicationController def create if policy.allowed? @project = Project.create!(project_params) render json: @project, status: :created else head :unauthorized end end private def project_params params.require(:project).permit(:name, :description) end def policy CreateProjectPolicy.new(current_user, redis) end def redis Redis.current end end def User < ActiveRecord::Base enum role: [:manager, :employee, :guest] end 

Результатом является чистый контроллер и модель. Объект политики инкапсулирует логику проверки разрешений, и все внешние зависимости внедряются из контроллера в объект политики. Все классы делают свою работу, а не другую.

Декораторы

Шаблон Decorator позволяет нам добавлять любые виды вспомогательного поведения к отдельным объектам, не затрагивая другие объекты того же класса. Этот шаблон проектирования широко используется для разделения функциональности между различными классами и является хорошей альтернативой подклассам для соблюдения принципа единой ответственности.

пример

Давайте предположим, что в представлении происходит много действий (вычислений):

• Заголовок отображается по-разному в зависимости от наличия значения title_for_head
• В представлении отображается изображение автомобиля по умолчанию, если не указан URL-адрес настраиваемого изображения автомобиля
• В представлении отображается текст по умолчанию, когда значения для бренда, модели, заметок, владельца, города и телефона владельца не определены.
• Вид показывает текстовое представление состояния автомобиля
• Вид отображает отформатированную дату создания объекта автомобиля

проблема

Представление содержит слишком много логики вычислений.

 #/app/controllers/cars_controller.rb class CarsController < ApplicationController def show @car = Car.find(params[:id]) end end #/app/views/cars/show.html.erb <% content_for :header do %> <title> <% if @car.title_for_head %> <%="#{ @car.title_for_head } | #{t('beautiful_cars')}" %> <% else %> <%= t('beautiful_cars') %> <% end %> </title> <% if @car.description_for_head%> <meta name='description' content= "#{<%= @car.description_for_head %>}"> <% end %> <% end %> <% if @car.image %> <%= image_tag @car.image.url %> <% else %> <%= image_tag 'no-images.png'%> <% end %> <h1> <%= t('brand') %> <% if @car.brand %> <%= @car.brand %> <% else %> <%= t('undefined') %> <% end %> </h1> <p> <%= t('model') %> <% if @car.model %> <%= @car.model %> <% else %> <%= t('undefined') %> <% end %> </p> <p> <%= t('notes') %> <% if @car.notes %> <%= @car.notes %> <% else %> <%= t('undefined') %> <% end %> </p> <p> <%= t('owner') %> <% if @car.owner %> <%= @car.owner %> <% else %> <%= t('undefined') %> <% end %> </p> <p> <%= t('city') %> <% if @car.city %> <%= @car.city %> <% else %> <%= t('undefined') %> <% end %> </p> <p> <%= t('owner_phone') %> <% if @car.phone %> <%= @car.phone %> <% else %> <%= t('undefined') %> <% end %> </p> <p> <%= t('state') %> <% if @car.used %> <%= t('used') %> <% else %> <%= t('new') %> <% end %> </p> <p> <%= t('date') %> <%= @car.created_at.strftime("%B %e, %Y")%> </p> 

Мы можем решить эту проблему с помощью драгоценного камня Draper, который перемещает всю логику в методы CarDecorator :

 #/app/controllers/cars_controller.rb class CarsController < ApplicationController def show @car = Car.find(params[:id]).decorate end end #/app/decorators/car_decorator.rb class CarDecorator < Draper::Decorator delegate_all def meta_title result = if object.title_for_head "#{ object.title_for_head } | #{I18n.t('beautiful_cars')}" else t('beautiful_cars') end h.content_tag :title, result end def meta_description if object.description_for_head h.content_tag :meta, nil ,content: object.description_for_head end end def image result = object.image.url.present? ? object.image.url : 'no-images.png' h.image_tag result end def brand get_info object.brand end def model get_info object.model end def notes get_info object.notes end def owner get_info object.owner end def city get_info object.city end def owner_phone get_info object.phone end def state object.used ? I18n.t('used') : I18n.t('new') end def created_at object.created_at.strftime("%B %e, %Y") end private def get_info value value.present? ? value : t('undefined') end end 

Результатом является аккуратный вид без каких-либо расчетов:

 #/app/views/cars/show.html.erb <% content_for :header do %> <%= @car.meta_title %> <%= @car.meta_description%> <% end %>​ <%= @car.image %> <h1> <%= t('brand') %> <%= @car.brand %> </h1> <p> <%= t('model') %> <%= @car.model %> </p> <p> <%= t('notes') %> <%= @car.notes %> </p> <p> <%= t('owner') %> <%= @car.owner %> </p> <p> <%= t('city') %> <%= @car.city %> </p> <p> <%= t('owner_phone') %> <%= @car.phone %> </p> <p> <%= t('state') %> <%= @car.state %> </p> <p> <%= t('date') %> <%= @car.created_at%> </p>  #/app/views/cars/show.html.erb <% content_for :header do %> <%= @car.meta_title %> <%= @car.meta_description%> <% end %>​ <%= @car.image %> <h1> <%= t('brand') %> <%= @car.brand %> </h1> <p> <%= t('model') %> <%= @car.model %> </p> <p> <%= t('notes') %> <%= @car.notes %> </p> <p> <%= t('owner') %> <%= @car.owner %> </p> <p> <%= t('city') %> <%= @car.city %> </p> <p> <%= t('owner_phone') %> <%= @car.phone %> </p> <p> <%= t('state') %> <%= @car.state %> </p> <p> <%= t('date') %> <%= @car.created_at%> </p> 

Завершение

Эти концепции должны дать вам базовое понимание того, когда и как вы можете реорганизовать свой код. Есть много инструментов для управления сложностью кода. Тщательно разместив свою логику с самого начала разработки, вы можете сократить количество времени, которое вам нужно потратить на рефакторинг.