Rails: используйте библиотеку моделей

Question

У меня есть некоторый опыт работы с asp.net.Когда бизнес-логика усложняется, вы хотите отделить репозитории и другие бизнес-классы от основного проекта пользовательского интерфейса.Вы не хотите менять проект пользовательского интерфейса, если вам нужно изменить бизнес-логику.

В .net я бы создал проект библиотеки и вставил туда бизнес-логику, таким образом я могу изменить библиотеку безвлияет на проект пользовательского интерфейса.

Где я должен разместить свою бизнес-логику?Если я сохраню это в своих моделях, то, похоже, очень быстро запутается, потому что есть много классов.

Как вы структурируете приложение rails, которое требует много классов с бизнес-логикой?

Answer 1

Общепринятое мнение при разработке приложения rails - помещать классы и модули, которые не имеют прямого отношения к представлениям, моделям или контроллерам, в каталог lib.

Обратите внимание, что rails 3 не загружает его автоматическипо умолчанию вам нужно будет указать в config/application.rb следующее:

config.autoload_paths += %W(#{config.root}/lib)

Создание драгоценного камня может быть другим вариантом, если вы хотите разделить свою бизнес-логику между несколькими приложениями, но это более сложная задача, чем простоположить все в lib.

Этот ответ будет хорошим началом, если вы хотите узнать больше об этом.

Answer 2

Рассматривали ли вы использование Rails :: Engine? Это даст вам возможность изолировать набор связанных моделей, контроллеров, представлений, маршрутов, помощников, миграций и тестов. Rails :: Engines также могут быть сконфигурированы как гем, поэтому использование движка в нескольких проектах становится возможным. Если вы хотите использовать свой движок в нескольких проектах, вам могут пригодиться версии gem.

http://edgeapi.rubyonrails.org/classes/Rails/Engine.html

Я предлагаю взглянуть на Devise, чтобы узнать, сколько можно сделать с помощью Rails :: Engine.

https://github.com/plataformatec/devise

Если вы хотите изолировать только небольшие фрагменты бизнес-логики, тогда ActiveSupport :: Concern может быть более подходящим.

http://api.rubyonrails.org/classes/ActiveSupport/Concern.html

Наконец, то, что я никогда не использовал, но выглядит интересно, это модульность. Пример из документации выглядит в принципе несколько похожим на ActiveSupport :: Concern.

class User < ActiveRecord::Base
  does "user/authentication"
  does "user/address"
end

https://github.com/makandra/modularity

Я буду отслеживать разные ответы, потому что пытаюсь решить ту же проблему.