2015-05-15 4 views
1

Мы используем Angularjs и ui-router. Обычно у нас есть макет каждой страницы, в которой используются представления. У нас есть вид фильтра, вид сортировки и вид с разбивкой по страницам; а также отображать виды, которые можно поменять местами.Функциональность разделения между контроллерами, которые должны взаимодействовать

Логически, когда происходят изменения, нам необходимо, чтобы какой-либо из этих контроллеров нам необходимо обновить displayData, если это необходимо. Изменения в фильтре должны запускать filterMethod, но также необходимо запустить сортировку, а затем логику разбиения на страницы, в то время как изменения в сортировке должны выполняться только с разбивкой по страницам, делая четкий порядок операций, когда каждый контроллер нуждается в его обновлении.

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

У нас возникли проблемы с поиском чистого способа заставить эти контроллеры «просто работать», чтобы мы могли подключить любой элемент управления, который мы хотим в uirouter, и иметь функцию. Проблема в основном связана с определением области. Если я сделаю очевидную вещь и каждый контроллер определит свой собственный метод updateData, когда будут внесены изменения, я столкнулся с проблемами определения области видимости, если я хочу, чтобы они вызывали последующие обновления следующего контроллера. Контроллер фильтра не может вызвать сортировку, потому что два контроллера не разделяют область. Я могу использовать широковещательные передачи, но что, если я хочу фильтр и диспетчер разбиения на страницы, но не сортировку? Как обеспечить, чтобы сортировка выполнялась до разбивки на страницы, если они оба присутствуют, но если диспетчер сортировки не существует, то существует возможность разбиения на страницы, которая может работать после фильтра?

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

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

Это похоже на общую проблему. Есть ли передовая практика или удобная технология для управления распределением функций между контроллерами?

ответ

0

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

Если у вас были данные (например: displayData), я мог бы предложить объект службы, но это скорее похоже на состояние приложения (например: orderBy), поэтому я думаю, что эти «настройки» должны жить на родительском контроллере.

+0

У меня действительно есть служба для сохранения состояния настроек, необходимого, потому что мы хотим, чтобы это состояние сохранялось на разных страницах. Однако как насчет логики управления элементами управления (включения и выключения фильтров и т. Д.) И запуска метода updateData? Если я полагаю, что все в одном контроллере не будут достаточно обширными? Разве не так много логики в одном классе является кодовым запахом? – dsollen

+0

Коммутационная логика живет как можно ближе к рассматриваемой области, то есть: подвид. Он использует службу или родительскую область для передачи информации. 'updateData' - это запах кода. – Sinetheta