2013-02-23 3 views
4

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

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

  1. Операции, отображаемые в обоих списках, должны быть ТОЛЬКО объектом в обеих областях, не так ли? Разве это не большой перенос привязок данных, поэтому обновление в одном месте будет отражено в другом?

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

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

  4. Возможно, нам захочется кэшировать транзакции в некотором вкусе клиентской памяти?

Итак, вопрос снова: где все это происходит? Все это забивается в $ rootScope и контролируется контроллерами? Делегирован на услугу?

Любое направление здесь, независимо от того, насколько расплывчатым, будет оценено.

+0

Вопрос, как представляется, обсуждает общий контекст, в то время как контент описывает более частный случай, чем пример. –

ответ

8

Что касается Углового, это то, что он оставляет модель до вас. Вам не нужно расширять какой-либо встроенный объект, чтобы он работал, это может быть любой объект, который вы хотите.

a) Да, но, как я уже сказал, это зависит от вас. Вы даже можете использовать реализацию модели Backbones, если хотите.

b) Возможно, в вашем объекте модели. Угловой предлагает ресурсное обслуживание, которое вы можете использовать. Вы можете определить свои собственные методы на этих ресурсах, чтобы это было хорошей отправной точкой.

c) Вы имеете в виду часть GUI или бизнес-логику? Угловой обрабатывает GUI для вас. Просто реализуйте функцию, которая удаляет транзакцию из списка, а Angular повторно отобразит ее для вас.

d) Опять же, это зависит от вас, чтобы реализовать или использовать библиотеку. Угловая - это в основном графический интерфейс с очень небольшим мнением о вашем слое модели/стойкости.

За последний вопрос; вы бы поставили большую часть логики в сервисах. Вашим Угловым контроллерам будут введены необходимые им службы и выставить функциональность для просмотра через область действия. Вы должны избегать добавления вещей в корневую область как можно больше, поскольку они будут по существу глобальными в ваших шаблонах.

+0

Отличный ответ! Я вроде как развязка, но кажется, что отходы нужно переопределить так много функциональности углового. Например, модель, которая следит за изменениями, - это то, что делает угловой масштаб очень хорошо. Реинжиниринг полностью отдельной системы, чтобы сделать это на стороне модели, а затем интегрировать ее с угловым $ watch/$ apply/etc, кажется, много ненужной массы и сложности, не так ли? – nicholas

+2

Я думаю, вопрос будет: есть ли хороший слой модели, который хорошо играет с угловым там? Я быстро просмотрел угловые ресурсы, а также несколько других фреймворков, таких как бриз и усиление. Какие-либо предложения? – nicholas

+0

Вы не должны переопределять наблюдаемые изменения модели. Если вам нужно следить за подобными изменениями, вероятность того, что вы должны поместить этот объект в свою область действия, так как вы, вероятно, хотите, чтобы ваш пользовательский интерфейс отражал изменения. Потребность в событиях на вашем бизнес-уровне по-прежнему существует, но это другое дело, чем просмотр области. События бизнес-уровня срабатывают при значительных изменениях, таких как сохранение объекта, а не для обновления свойства объекта. Однако вы можете использовать Angulars $ rootScope, чтобы излучать эти события. –