>> но стандартный AuthorizeAttribute принимает только константные строки
если чуть расширить реализацию стандартного FilterAttrubuteFilterProvider то в фильтру можно отдать любой тип, а не только переменные уровня компиляции. этот тип вполне может быть контектом доступа к данным, циклом жизни которого управляет кто-то другой, например контейнер.
напомню изначальный сценарий:
>>а если вам нужно разным цветом строчку в табличке нарисовать в зависимости от статуса? неужели цвет из контроллера передавать будите?
ваш ответ был утвердительным.
вы согласны с тезисом, что передавать значение цвета элемена UI из контроллера — есть нарушение принципа разделения ответственности в MVC приложении как бы удобно это не выглядело?
>>То есть семантика слова View, ViewResult и ViewEngine (а так же их «случайное» совпадение с V из триады MVC) — это мое личное мнение, а не банальный английский язык?
View не обязательно то, что умеет отображать цвета и представляется html'ом. представление в общем случае может быть любым.
если вы считаете «цвет строчки в табличке» данными приложения, а не параметром представления — я с вами никак не могу согласиться.
еще маленький пример. представьте что нужно передать не цвет, а много всего (размеры, отступы, цвета, шрифты). вам сразу же захочется передавать это все одним css классом (иначе html будет уныл). если так, то у вас появляется зависимость логики от представления со всеми вытекающими.
>> Говоря «View» контроллер _ожидает_, что там будет именно представление. А раз представление — значит, цвет имеет смысл, кто и как его отрисует — вопрос пятнадцатый.
настоящий контроллер ожидает что метод View() вернет наследника ActionResult, а кто там ему что в респонс напишет — определяется в конфигурации приложения.
>>Не вы ли написали: “другой ViewEngine который вместо рендеринга html будет поросто возвращать модель в xml или json»?
я решал подобную задачу (делал restful сервис) но там я вообще выкинул все ViewEngine и написал своего наследника ActionResult, который в зависимости от заголовков в реквесте формировал респонс в правильном формате.
мы с вами расходимся в тезисе, что свойство «цвет строчки в таблице» является частью бизнес логики. тут уж ничего не поделать.
>>Вот как раз контроллер-то и в курсе, больше некому. Именно контроллер говорит, что возвращать — View или Json или НашГениальныйActionResult.
View() это метод базового класса, который на основе сконфигуренного в web.config ViewEngine выполнит действие по преобразованию модели в Response для клиента. мы можем использовать любой ViewEngine, не обзязательно Razor. Такмим образом контроллер об этом не знает.
Json это наследник ActionResult который к ViewEngine не имеет отношения.
сценарии тестирования UI — отдельная песня. лично я не склонен их автоматизировать, но даже если так, то данный кейс должен проверятся именно «там».
контроллер не в курсе, кто и как будет представлять модель данных пользователю. возьмем, например, другой ViewEngine который вместо рендеринга html будет поросто возвращать модель в xml или json. зачем нам тут свойство «цвет»?
опс, неверно понял смысл с первого раза.
>> в реальных view if опираются на данные представления (“надо показать»), а не бизнес-логику («если пользователь — админ»).
а если вам нужно разным цветом строчку в табличке нарисовать в зависимости от статуса? неужели цвет из контроллера передавать будите или всеже @helper метод?
>> с самого начала возникла необходимость из шаблона обращаться к методам основного объекта веб-приложени
Как уже было отмечено, вы концептуально нарушаете паттерн MVC
>>Стандартный класс System.Web.Mvc.ViewPage не предоставляет удобного функционала для этого
зато есть HtmlHelper и куча расширений к нему. в вашем случае можно использовать Html.RenderAction для вынесения всей логики по вызову «объекта Main» в контроллер.
если чуть расширить реализацию стандартного FilterAttrubuteFilterProvider то в фильтру можно отдать любой тип, а не только переменные уровня компиляции. этот тип вполне может быть контектом доступа к данным, циклом жизни которого управляет кто-то другой, например контейнер.
{
PermissionManager permissionManager = new PermissionManager();
плохо инстанциировать тип PermissionManager прям в методе OnAuthorization. лучше отдавать его классу DynamicAuthorizeAttribute в виде иньекции.
пример тут
>>а если вам нужно разным цветом строчку в табличке нарисовать в зависимости от статуса? неужели цвет из контроллера передавать будите?
ваш ответ был утвердительным.
вы согласны с тезисом, что передавать значение цвета элемена UI из контроллера — есть нарушение принципа разделения ответственности в MVC приложении как бы удобно это не выглядело?
View не обязательно то, что умеет отображать цвета и представляется html'ом. представление в общем случае может быть любым.
если вы считаете «цвет строчки в табличке» данными приложения, а не параметром представления — я с вами никак не могу согласиться.
@helper GetMessage(MyMessage msg)
{
if(msg.Size > 15)
{
<img картинка с гирей
}
if (msg.IsImportant)
{
<span class=жирно и красиво @msg.Text</span
}
else
{
@msg.Text
}
}
и далее во View там, где нужно нарисовать сообщение, вызываем наш хелпер метод:
@GetMessage(item)
в приведенном вами примере нет бизнес логики.
это ваше личное мнение, которое к MVC отношения не имеет )
настоящий контроллер ожидает что метод View() вернет наследника ActionResult, а кто там ему что в респонс напишет — определяется в конфигурации приложения.
>>Не вы ли написали: “другой ViewEngine который вместо рендеринга html будет поросто возвращать модель в xml или json»?
я решал подобную задачу (делал restful сервис) но там я вообще выкинул все ViewEngine и написал своего наследника ActionResult, который в зависимости от заголовков в реквесте формировал респонс в правильном формате.
мы с вами расходимся в тезисе, что свойство «цвет строчки в таблице» является частью бизнес логики. тут уж ничего не поделать.
View() это метод базового класса, который на основе сконфигуренного в web.config ViewEngine выполнит действие по преобразованию модели в Response для клиента. мы можем использовать любой ViewEngine, не обзязательно Razor. Такмим образом контроллер об этом не знает.
Json это наследник ActionResult который к ViewEngine не имеет отношения.
контроллер не в курсе, кто и как будет представлять модель данных пользователю. возьмем, например, другой ViewEngine который вместо рендеринга html будет поросто возвращать модель в xml или json. зачем нам тут свойство «цвет»?
представьте сбебе тесты контроллера по первому сценарию, или задачу по редизайну, которая приводит к изменению свойств модели данных
>> в реальных view if опираются на данные представления (“надо показать»), а не бизнес-логику («если пользователь — админ»).
вобщем да — все так.
а если вам нужно разным цветом строчку в табличке нарисовать в зависимости от статуса? неужели цвет из контроллера передавать будите или всеже @helper метод?
Как уже было отмечено, вы концептуально нарушаете паттерн MVC
>>Стандартный класс System.Web.Mvc.ViewPage не предоставляет удобного функционала для этого
зато есть HtmlHelper и куча расширений к нему. в вашем случае можно использовать Html.RenderAction для вынесения всей логики по вызову «объекта Main» в контроллер.