Один контроллер с многоуровневыми моделями? Я делаю это правильно?
Мое веб-приложение, вплоть до этой точки, было довольно прямым. У меня есть Пользователи, Контакты, Назначения и несколько других вещей справиться. Все они легки - это - всего одна модель на раздел, таким образом, я просто сделал леса для каждого, затем изменил код лесов для установки моей потребности. Довольно легкий...
К сожалению, у меня есть проблема на этом следующем разделе, потому что я хочу, чтобы раздел 'Financials' моего приложения был больше подробно, чем другие разделы который я просто леса. Например, когда пользователь нажимает на ссылку 'Contacts' на панель навигации, она просто показывает список контактов, довольно прямых, и соответствует лесам. Однако, когда пользователь нажимает на ссылку 'Financials' на панель навигации, я хочу показать банковские счета слева от страницы и нескольких транзакций справа.
Таким образом, вкладка финансовых документов будет в основном работать с данными из двух моделей: транзакции и bank_accounts. Я думаю, что должен сделать модели (транзакции и bank_accounts) и затем сделать контроллер под названием Финансовые документы, затем я могу запросить модели от контроллера Финансовых документов и отобразить страницы в app/views/financials/
Я корректен в этом расположении приложения? Я никогда не работал с больше, чем основы лесов, таким образом, я хочу удостовериться, чтобы я разобрался в этом!
Спасибо!
3 ответа
Если вам удобно строить леса, я бы посоветовал вам создать основу для обеих
транзакций: скрипт / сгенерировать транзакцию каркаса financial_id: integer ...
bank_accounts : скрипт / генерация скаффолда bank_account financial_id: integer ...
и financials скрипт / генерация скаффолда financials ...
В модели транзакций добавьте следующее:
class Transaction < ActiveRecord::Base
belongs_to :financial
end
В модели bank_account добавьте следующее:
class Bank_account < ActiveRecord::Base
belongs_to :financial
end
В своей финансовой модели добавьте следующее:
class Financial < ActiveRecord::Base
has_many :transactions
has_many :bank_accounts
end
Теперь из вашего финансового контроллера вы можете использовать что-то вроде этого:
def index
@financial = Financial.find(params[:id])
#This fetches all bank_accounts related to financial
@bank_accounts = @financial.bank_accounts
#This fetches all transactions related to financial
@transactions = @financial.transactions
end
В ваших представлениях вы можете просмотреть все банковские счета, принадлежащие определенному финансовому сектору, просто выполнив следующие действия:
<% @bank_accounts.each do |bank_account| -%>
<%=h bank_account.something_here %> <!-- something_here is the column name corresponding to your bank_account table. -->
<%=h bank_account.something_here %> <!-- something_here is the column name corresponding to your bank_account table. -->
<%=h bank_account.something_here %> <!-- something_here is the column name corresponding to your bank_account table. -->
.
.
.
<% end -%>
В ваших представлениях вы можете просмотреть все транзакции, принадлежащие определенному финансовому учреждению, добавив нечто подобное:
<% @transactions.each do |transaction| -%>
<%=h transaction.something_here %> <!-- something_here is the column name corresponding to your bank_account table. -->
<%=h transaction.something_here %> <!-- something_here is the column name corresponding to your bank_account table. -->
<%=h transaction.something_here %> <!-- something_here is the column name corresponding to your bank_account table. -->
.
.
.
<% end -%>
Помните, создавая новая транзакция / банковский счет использует идентификатор, принадлежащий конкретному финансовому. Надеюсь это поможет. Ваше здоровье! :)
У меня нет большого опыта работы с Ruby on Rails или MVC в целом, но я думаю, что вы все делаете правильно. Обычно вам нужен объект модели (и, соответственно, таблица базы данных) для ресурсов, ориентированных на данные ... То есть ваши модели должны соответствовать вашим «существительным». Действия вашего контроллера - это ваши «глаголы», и для меня имеет смысл классифицировать их, как вам нравится.
В этом случае я бы сказал, что добавление кучи «глаголов» в financials , которые взаимодействуют с двумя типами объектов модели по мере необходимости, имеет смысл, ЕСЛИ И ТОЛЬКО ЕСЛИ это имеет смысл для вас для вас организовать это вот так. (Имейте в виду, что вы также можете оценить, насколько хорошо организованы и интуитивно понятны соответствующие URL-адреса, хотя я уверен, что большинство пуристов MVC добавят, что вам никогда не следует полагаться только на изучение URL-адресов!)
Итак, в итоге, Я думаю, ты делаешь все прямо здесь, если это имеет для тебя смысл. Да, вам придется написать свои представления и действия контроллера самостоятельно, хотя вы можете начать использовать скрипт ruby / сгенерировать контроллер financials action1 action2 [...] ; это, по крайней мере, дает вам скелеты файлов представления и пустые действия контроллера.
Мне кажется, что вам нужны два представления:
Однако, когда пользователь нажимает на ссылку "Финансы" на панели навигации, я хочу показать банковские счета в левой части страницы, а несколько транзакций - в правой.
Помните, что один экран не всегда означает одно представление в MVC. Концептуально, представление просто отображает данные модели, чтобы пользователь мог сделать с ними что-то значимое с помощью действий контроллера. Rails немного запутывает это, заставляя вас создавать файл в каталоге views/ для каждого экрана, поэтому легко подумать, что один экран означает одно представление. Однако в Rails можно также вызывать макеты внутри представлений, и эти макеты сами являются представлениями.
Размещение транзакций и счетов в отдельных представлениях означает, что у каждого из них будет свой контроллер для обработки взаимодействия пользователя с каждым сегментом данных. Контроллер счета, например, будет обрабатывать событие, когда пользователь выбирает счет для просмотра дополнительной информации о нем. Это приведет к выборке транзакций для показа пользователю. Затем пользователь может взаимодействовать с транзакцией, пытаясь согласовать, аннулировать или оспорить ее. Это вызовет логику в контроллере транзакций.
Несмотря на то, что это хорошая работа по удалению связи из ваших контроллеров, может показаться, что это связывает два представления. Однако связь односторонняя: список счетов включает логику, специфичную для представления транзакции (т.е. обновление при выборе счета). Представление транзакции остается пригодным для повторного использования в других областях приложения. По большей части, список счетов также остается пригодным для повторного использования, особенно если вы выделите его в отдельный макет. Единственное отличие, которое вам понадобится для этого конкретного экрана, - это обработка того, когда пользователь нажимает на счет.
Если вы объедините все в представление финансов, все еще можно сохранить свободную связь, но сделать это становится сложнее. Дополнительный слой требует дополнительных усилий и может подсознательно подтолкнуть вас к объединению всего вместе.
Конечно, любой из этих способов работает, и вы можете легко утверждать, что окончательный дизайн - это упражнение, которое лучше оставить на усмотрение разработчика. Я просто предлагаю свою интерпретацию того, как можно наиболее точно придерживаться паттернов, которые Rails пытается направить разработчиков на использование.