KnockoutJS - Множественные частичные представления внутри основного вида?

Я пытаюсь подключить существующее приложение asp mvc для использования knockoutjs (pure js/html), поскольку мне больше не нужна какая-либо функциональность в asp mvc. Однако одной из проблем, которую я могу предвидеть, является то, как я обрабатываю некоторые из моих страниц.

У меня есть одна страница, которая содержит около 12 частичных представлений, каждая частичная имеет свою собственную модель. Теперь с Knockout JS кажется, что на самом деле у вас должно быть только 1 viewmodel/view на странице, однако на моей странице содержится большой объем информации, разделы будут сродни:

  • Информация о клиенте
  • Адрес клиента
  • Клиентские заказы клиента
  • Карты клиентов
  • Клиентские фонды
  • ...

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

Поэтому я немного не уверен, как это сделать в нокауте, так как это предпочло бы иметь его как одну большую модель, которую я был бы счастлив делать, но он содержит много информации. Как и несколько форм, так как вы можете обновить свой адрес, не обновляя все остальное.

Так должен ли я просто сделать одну большую модель для этого представления и просто справиться с этим? или есть способ взглянуть друг на друга?

ОТВЕТЫ

Ответ 1

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

Однако, чтобы сделать вещи управляемыми, я гарантирую, что каждый код манипулирования Javascript написан в его собственном частичном представлении. Это облегчает отслеживание функциональности и соответствующего кода.

Таким образом, в основном вы заполняете свой основной объект массива Customers на главной странице, а затем вызываете функции для заполнения деталей, адресов и т.д., которые определены соответственно в каждом частичном представлении.

Ответ 2

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

Лучшим решением является создание паба/подсистемы поверх ko.subscribable. Связь между моделями просмотров облегчается путем управления подписками на различные события. Это немного больше работы, но она будет выплачивать дивиденды в будущем.

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