frontend и бэкенд должны быть обработаны различными контроллерами?

То, что я делаю в такой ситуации, довольно сильно изменилось за последнее время. Текущий подход таков:

Я разделяю контроллеры на основе требований к доступу. Это дает мне четкую ментальную модель и очень простой способ проверки контроля доступа (и его тестирования).

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

Такой подход также позволяет легко использовать стандартные рестуктивные реализации контроллеров, такие как InheritedReseses. реализации, такие как InheritedResources.

Обратите внимание, что вы можете повторно использовать многие представления, если одна и та же функциональность требуется для различных видов доступа.

Таким образом, у меня будет что-то вроде этого:

### lets start with routes

# this is basically guest access level. you can only list it and see details
map.resources :books, :only => [:index, :show]

namespace :my do |my|
  # this will require at least login.
  # index and show will be basically same as at the guest level. we can reuse the views
  my.resources :books
end

namespace :admin do |admin|
  # this will require admin login
  admin.resources :books
end

# now the controllers

# this might be just enough of a controller code :). the rest goes into model.
class BooksController < InheritedResources::Base
  actions :index, :show
end

module My
  class BooksController < InheritedResources::Base
    before_filter :require_user

    protected
    def begin_of_association_chain
      # this will force resources to be found on current_user.books.
      # so if you go to /my/books/123 and book 123 is not your book you will get 404
      current_user
    end
  end
end

module Admin
  class BooksController < InheritedResources::Base
    before_filter :require_admin

    # this controller is essentially unrestricted. you can get/edit/update any book
    # and you can have separate view template for index too
  end
end



## Views
# well, this is the part that I like the least in this approach, but
# I think the good outweight the bad.
# I see 2 ways to reuse the views w/o writing lots of ugly customization code for the InheritedResources
# 1) render 'parent' views inside templates. i.e. like:
# my/books/index.html.haml:
!= render :file => "/books/index"

# or just link the templates on the filesystem level with symlinks.
# (or if all of them are the same you can link the directory)

Использовать два текущих, если есть два модуля 1] Администратор 2] Пользователь

Скажите

class BookUserController < ApplicationController
  #Here layout is used will be of layouts/application.html.erb
  #Here all the methods which user can will be present 
end


class BookAdminController < ApplicationController
  layout 'admin'  #here we set the layout is layouts/admin.html.erb 

end

ЕСЛИ Только одну страницу вы хотите показать администратору, вы можете используйте один контроллер и два метода

class BookUserController < ApplicationController
  layout 'admin', :only=>['index_admin']

  def index_admin


  end

  def index



  end


end

ИЛИ

class BookUserController < ApplicationController
  def index_admin

    render :action=>'index_admin', :layout => false
  end

  def index



  end


end

Когда мне нужна четко разделенная область администрирования, я предпочитаю решение с двумя контроллерами для одного ресурса. Admin :: BooksController в подкаталоге admin / для интерфейса администратора со всеми действиями и общедоступный BooksController, который имеет только методы index и show в зависимости от потребностей.