Является ли обработка запросов / доступ к базе данных в ячейках хорошей практикой? и больше о MVC с клетками и ООП

Мне просто интересно, является ли это хорошим подходом для создания модельного запроса внутри определения ячейки....?

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

Для чего мне это нужно?

У меня есть категории с предметами. Я хочу реализовать результаты поиска в виде ячейки. Результаты поиска должны быть представлены несколько иначе в соответствии с тремя случаями:

  • поиск всех предметов в указанной категории

Например, пусть категория будет "животные" (эта категория содержит в базе данных предметы о собаках, кошках и птицах), тогда я должен увидеть в браузере:

 Category Items
    dog
    cat
    bird
  • поиск предметов, похожих на указанный "шаблон" во всех категориях

Например, пусть pattern будет "do":

Similar Items
   Animals
      dog
   Cars
      dodge
  • поиск предметов, похожих на указанный "шаблон" внутри указанной "категории"

Например, пусть pattern будет "do", а категория - "animal":

Category Items
    dog
Similar Items
    Cars
       dodge

Я решил поэкспериментировать с гемами клеток, чтобы реализовать этот материал...

Это то, что я хочу отобразить через ячейку: (app/ cell / search_result / display.html.haml)

%h1
  = @category_items[:title]
%ul
  - for i in @category_items[:items]
    %li
      = link_to "#{i.code} #{i.summary}", category_item_path(i.category.name, i.code)

%h1
  = @similar_items_by_category[:title]
%ul
  - for cat in @similar_items_by_category[:items_by_category].keys
    %li
      = "#{cat.name}"
      %ul
        - for i in @similar_items_by_category[:items_by_category][cat]
          %li
            = link_to "#{i.code} #{i.summary}", category_item_path(i.category.name, i.code)

Это моя ячейка: (app/ cell / search_result_cell.rb)

class SearchResultCell < Cell::Rails

  def display options
    setup! options

    render
  end

  def setup! options

    #some code here that defines
    # category_items_title, like "Category Items"
    # array_of_found_items
    # similar_item_title, like "Similar Items"
    # hash_of_found_items_by_category
    #this code will be different for each search case in correspondent overridden function

    @category_items = { title: category_items_title, items: array_of_found_items }
    @similar_items_by_category = { title: similar_item_title, items_by_category: hash_of_found_items_by_category }
  end

end

Я собираюсь иметь отдельный класс ячеек для каждого "поискового" случая, извлечь его из SearchResultCell (возможно, я переименую его в что-то вроде GenericSearchResultCell) и переопределить настройку! функция для каждого случая... А затем будет использовать строитель, чтобы определить, какой класс для сборки...

Это мой взгляд: (app/ views / items / index.html.haml)

= render_cell :search_result, :display #, ... - and here some options...

Теперь ВОПРОСЫ:

  1. Должен ли я сделать реальные поисковые запросы внутри "установки!" функция в клетке? А затем заставьте мой контроллер ItemsController просто "проанализировать" маршрут и предоставьте эти опции для передачи в мой SearchCell...

  2. Или я должен сделать так, чтобы мой ItemsController отвечал как за "разбор" маршрута, так и за выполнение поисковых запросов (определяя array_of_found_items и hash_of_found_items_by_category самостоятельно)? А затем просто передать все эти вещи в SearchCell в качестве параметров...

  3. Достойны ли все эти "клеточные эксперименты"? Есть ли более удобный способ реализовать мои "поисковые" представления и контроллеры?

Источник

2 ответа

Решение

Вы должны полностью отделить свою логику запросов от контроллера и рендеринга. Введите класс ItemsFinder он выполняет все операции поиска и возвращает набор результатов.

Теперь, когда у вас есть подходящие наборы моделей, о которых можно поговорить, вы можете перейти к рендерингу. Обычно, когда представление не слишком сложное (нет if-else, не слишком много вложенных партиалов), "старый" путь паролей Rails просто идеален.

Тем не менее, часто вы хотите переопределить только небольшой фрагмент суб-суб-субчастичного, и именно здесь вступает в силу наследование ячеек. Это также побуждает вас определять интерфейсы для ваших "частичных функций", так что имейте это в виду.

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

Источник

Хороший способ думать о геме клеток - это то, что он предоставляет частичную часть, поддерживаемую контроллером. Другими словами, ваше представление может вызывать контроллер, который затем будет визуализировать частичное. Это замечательно, когда частичное отображается во многих представлениях и содержит значительную обработку данных, которую вы не хотите повторять на каждом контроллере.

Однако это не похоже на ваш случай. Вы упоминаете только один контроллер, ItemsController, который будет отображать результаты поиска, поэтому вся обработка данных может быть выполнена в этом контроллере.

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

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

Источник
Другие вопросы по тегам