Если верить Скотту Гатри и его компании (1, 2), то одна из [используемых] философий дизайна ASP.NET MVC Framework — DRY (Don’t Repeat Yourself). Это хорошо, конечно, но одна вещь меня до сих пор не оставляла в покое, т.к., имхо, она еще недостаточно «осушена» (DRY-ed ). И эта вещь — проверка прав доступа в UI-представлениях (view).

Чему обычно «учат» люди, пишущие в своих блогах про MVC, когда  дело доходит до момента, что «вот этот кусок HTML нужно показывать не всем пользователям»? В лучшем случае (из того, что видел я, если видели лучше — делитесь ) предложат сделать helper для проверки типа «является ли текущий пользователь админом». На первый взгляд кажется логичным.

Но, ведь точно такие же проверки мы уже, наверняка, прописали в виде атрибутов к нашим action-методам в наших контроллерах. И любой активный элемент пользовательского интерфейса в нашем view, такой как кнопка, ссылка, и т.д., будет связан именно с action-ом какого-либо контроллера. По сути, у нас уже описаны условия, которые уже описывают когда есть смысл рендерить ту или иную часть пользовательского интерфейса. Ведь будет глупо показывать кнопку «Удалить», если контроллер вернет ошибку, сказав, что нам не хватаем прав? И, кроме того, если мы при написании своих view снова используем язык пользователей и ролей, как это делали при описании прав на action-методы, то мы снова повторяем себя. Ладно, если таких поверок минимум, или изменений в правах не будет еще лет 100, или вместо поддержки нашего кода все будет переписано заново. Не ракеты строим, все таки Хотя, последний пункт — это уже откровенное неуважение своего же труда.

И, мне кажется, было бы логично делать проверку UserCan(<ссылка на LawsController Decline>), это ведь и читается легче: «может ли пользователь отменять новые законы?», и код во view из «если пользователь — президент, то покажи кнопку Отменить» превращается в «если пользователь может отменять новые законы, то покажи ему эту кнопку».

Имхо, самая большая проблема тут — ссылка на action-методы. Эта проблема, в общем-то, уже решалась в MVC Futures для Html.ActionLink<>, и в дополнительных t4 шаблонах, выложенных на codeplex в релизах mvc. Еще важно разделять action-ы с одинаковыми именами. Но, т.к. все это работает в рамках .NET Framework, то все наши методы либо имеют разные параметры, либо разные имена [методов], чем можно пользоваться. Так же можно пользоваться атрибутами AcceptVerbs (например, трансформировать проверку в UserCan(Post, <ссылка на LawsController Decline>)), и в этом случае, возможно, не придется париться по поводу различий в аргументах, будет достаточно лишь имени action-а, что делается простейшим t4-шаблоном.

Единственное НО — производительность. Выбрав путь MVC Futures (передача лямбда-выражения, использующего нужную функцию) мы теряем в производительности, т.к. это означает, что мы в рантайме анализируем свой код. Выбрав путь ссылок на имена action-методов мы можем сделать преобразование вызовов проверки UserCan компилятором в проверки типа IsAdmin, сохранив производительность в рантайме, но скорее всего потеряем возможность автоматического изменения всех ссылок при переименовании action-методов (так ли это важно, если у нас это редкость, да и на момент компиляции нас предупредят об изменениях?).

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

При переезде сайта на новый домен есть две рекомендации: сделать серверный (301) редирект со страниц старого сайта на новый, и прописать правильный robots.txt. Об этом написано, например, в самом Яндексе: тут и тут, ну и в основном в рекомендациях упоминаются как одновременное действие.  При этом, говорят, что все может затянуться от 2-х недель до 2-х месяцев.

В конце июля мне приспичило выпонить такой перенос, все было сделано как я и описал выше. Но в середине октября (2.5 месяца) после очередного апдейта тИЦ в выдаче Яндекса до сих пор красовался старый домен, при этом в индексе осталась лишь одна главная страница, да еще тИЦ старого домена был снижен, а новый был с нулевым тИЦ. Посещаемость, естественно стала много меньше. При этом гугл выполнил перенос очень хорошо: сначала в выдаче были оба домена, а через пару месяцев старый вовсе пропал из выдачи, уступив место новому.

Кроме того, меня сильно волновал вопрос, что делать с упоминанием в Яндекс.Каталоге старого домена: удалят ее, отредактируют сами, или же нужно написть им, чтобы поменяли. На мой вопрос в саппорт Яндекса, в котором я написал, что сделал и редирект и robots.txt более 2-х месяцев назад, пришел следующий ответ:

User-agent: Yandex
Disallow:
Host: url_нового_сайта

Другими словами, эти два пункта — разные способы с разными результатами. И сделав полный редирект я наткнулся на ошибку индексации (Яндекс страницы с редиректом считает ошибочными), и потерял тИЦ. Однако, заявленные 2 месяца уже прошли давно, да и сообщить им я уже сообщил, а результата нет никакого. Поэтому я им ответил, что все это было сделано два с половиной месяца назад, и на всякий случай  убрал 301 редирект, вдруг тИЦ вернется.

Фокус с возвращением тИЦ не прошел, и сегодня (еще 2 месяца) при очередном апдейте тИЦ на новый домен перенесли уже меньший тИЦ, но все-таки его перенесли. В выдаче старый домен был заменен на новый где-то в начале декабря, практически одновременно с изменением записи в Я.Каталоге. Итого на все это ушло почти 5 месяцев.

В новых рекомендациях по переносу сайтов на новый домен, кстати, рекомендуют сначала сделать второй способ (для Яндекса), потом первый (для Гугла).

Я как-то уже писал по поводу удивления от анонса ASP.NET Dynamic Data (1, 2), который реализует идеологию, очень схожую с одной из наших разработок. И как-то с тех пор я особо не изучал этот вопрос, чему способствовал и тот факт, что к моменту анонса Dynamic Data у нас уже была рабочая версия HOLMS, да и первый релиз dynamic data оказался далеко не самым удобным решением с точки зрения реальных разработок для реальных заказчиков (хотя, ценных идей там достаточно и без этого). Но вот недавно мне удалось найти чуть больше информации по этому поводу.

Оказывается, этому всему есть вполне доступный термин: Model-driven development/engineering (MDD), или по русски — разработка, управляемая моделями.

Небольшое отступление. Мне такой перевод этого термина не очень нравится: как будто бы нет больше руководителей, нет заказчиков, а есть только модели, и они всем управляют. Матрица прямо какая-то Вариант «разработка на основе моделей» тоже не подходит: мы и так обычно моделируем систему, а потом разрабатываем, не понятны различия. Слово «driven» тут скорее нужно было перевести синонимом значения «приводимый в движение». Может быть, «разработка через моделирование»? Или «разработка средствами моделирования»? Указавая на тот факт, что первоначально создается модель, и на основе нее «все» и работает. «Все» в кавычках, т.к. в реальных задачах 100%  конечно же так не сделать, но ускорить раз в 5 50-70% работ — вполне реально в ряде задач, главное правильно применить. А в остальных 30-50% — еще подумать По крайней мере с нынешними средствами.

Есть другие предложения по литературному переводу?

Вернемся обратно к MDD. Самая известная инициатива, связанная с этим подходом, по версии википедии — инициатива Object Management Group, которая даже зарегистрировала товарный знак Model-Driven Architecture, и хочет стандартизировать подход, сделав в светлом будущем возможным разработку ПО на UML То, что этим занимается OMG — неудивительно, ведь MDD-подход основан на объектно-ориентированном программировании. А во что упоминают вскользь, так это то, что к OMG в сентябре 2008 года присоединилась и Microsoft. В варианте MS, по сути, по картинкам в дизайнере БД (как и в UML) делается приложение (или его часть), как и у OMG. Нету только реализации активностей и прочих прелестей, т.е. программировать все еще надо.

Но почему MS подключилась к OMG позже официального выхода Framework 3.5 SP1 (август 2008), в релизе которого и были запущены такие вещи как Dynamic Data и MVC Framework? И много позже анонса всего этого (декабрь 2007), и, естественно, много позже, чем они начали над эти работать? Просто не были в курсе про инициативу OMG, или же осознанно отложили?

PS. Вот еще интересная ссылка: nreco.

UPD 22.06.2010: в продолжении темы model-driven development предлагаю ознакомиться с идеей ActionScheme-driven Development

Сегодня вместе с Юрой Корчёмкиным наткнулся на интересную особенность, связанную с парсингом командной строки.

Наткнулся вот таким интересным способом: запустил свою программу с аргументом /dir “c:\temp\”

Стандартное желание, не правда ли?

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

Прочитать остальное »