Я был в похожей ситуации несколько месяцев назад. Я обнаружил, что такие инструменты, как Zend_ACL, прекрасно работают, если вы просто проверяете уровень доступа к одному элементу (или достаточно низкое их количество). Сбой, когда вам нужно получить огромный список элементов, доступ к которым разрешен пользователю. Я разработал собственное решение этой проблемы, используя шаблон Business Delegate . BD предоставляет бизнес-логику, которую можно применять в определенном контексте. В этом сценарии логика SQL была доставлена и использована в качестве условия фильтрации в подвыборах. Смотрите следующие диаграммы:
(источник: epsi.pl )
И диаграмма последовательности, которая иллюстрирует порядок вызовов:
(источник: epsi.pl )
Я писал об этом решении в блоге , к сожалению, все это на польском языке, но вам могут пригодиться фрагменты кода и диаграммы. Что я могу сказать, реализация не является легкой задачей, но с точки зрения производительности она является рекордсменом по сравнению с итеративной проверкой доступа для каждого элемента в списке. Более того, инфраструктура выше обрабатывает не только один тип элементов в списке. Он может использоваться при доступе к различным спискам, будь то список городов, стран, продуктов или документов, если элементы в списке реализуют интерфейс IAuthorizable
.