2017-02-10 35 views
2

Я новичок в Ruby on Rails. Исходя из C# и фона Java, Ruby on Rails кажется bizzare, но интересным в то же время. Это похоже на переход от объектно-ориентированного мира на класс к концепции прототипирования JavaScript или даже к функциональному языку.Являются ли проблемы в Ruby on Rails заменой для классов обслуживания в MVC?

В любом случае, в традиционном приложении C# или Java MVC я стараюсь максимально упростить мои модели и контроллеры, извлекая бизнес-логику в классы обслуживания. Мои модели - это только POCOs/POJOs (с некоторыми расчетными полями и валидацией в лучшем случае). И мои контроллеры просто обрабатывают входящие запросы (в основном полагаясь на инъекцию зависимостей), а затем возвращают представление или JSON.

Тем не менее, я не вижу четкой картины в мире RoR. Некоторые люди склонны вкладывать всю свою бизнес-логику в контроллеры, некоторые помещают их в модели (с ActiveRecords, это имеет смысл, хотя мне это не нравится).

И тогда существует концепция проблем. Являются ли они подходящим местом для извлечения моей бизнес-логики вместо использования сервисов? Если да, можете ли вы включить пример правильного использования Concers? Я все еще борюсь с концепцией модулей (больше ли они пространств имен или, скорее, интерфейсов)? Как сказал вначале, Ruby кажется для меня совершенно новой галактикой.

ответ

1

Я бы сказал, что реакция jpgeek является частью ответа. Очень много движений по объектам обслуживания для очистки жирных моделей или больших действий контроллеров. Просто создайте папку в приложение/услуг и создавать классы услуг, как:

class TargetDestructionService 

    def initialize(shooter, target) 
    @shooter = shooter 
    @target = target 
    end 


    def execute 
    #Lot of code that causes the destruction of the target. 
    end 
end 

Тогда в вашей модели или контроллера вы бы назвали:

TargetDestructionService.new(EvilRobot.new, Human.new).execute 

Вот хорошая статья о нем: https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services

1

Этот вопрос может попасть в сорняки немного, поскольку он приносит много личных предпочтений. Но вот мое занятие.

Во-первых, проблемы не заменяют классы обслуживания. Озабоченность - это чистый и отличный способ управления вашими миксами. Если вы новичок в Ruby, mix-ins - это, в основном, способ ввода методов экземпляра и/или класса в существующие классы. Например, если эти классы:

class EvilRobot < ActiveRecord::Base 
    def destroy(target) 
    ... 
    end 
end 

class OrneryTeenAger < ActiveRecord::Base 
    def destroy(target) 
    ... 
    end 
end 

вы могли бы высыхают код с:

require 'active_support/concern' 
module EvilTools 
    extend ActiveSupport::Concern 

    included do 
    def destroy(target) 
     ... 
    end 
    end 
end 

class EvilRobot < ActiveRecord::Base 
    include EvilTools 
end 

class OrneryTeenAger < ActiveRecord::Base 
    include EvilTools 
end 

Я думаю, что подавляющее большинство разработчиков Rails, включая меня, пойти на тук-модели, тонкий дизайн контроллера. Просто, как жир, хотя это вопрос вкуса. Я также склонен перемещать функциональность к классам под lib, если они не подходят логически в пределах модели или извлекаются в движок или драгоценный камень.