Нет, это именно структурная типизация. Ошибки «несовместимости» детектируются не в рантайме, а в момент компиляции. Например, при попытке использования foreach с объектом, у которого нет метода GetEnumerator, вы получите ошибку компиляции.
Это не совсем верно. Структурная типизация поддерживается в очень ограниченных масштабах. Например, в foreach итерируемый объект должен иметь метод GetEnumerator, возвращающий объект с методом MoveNext и свойством Current. Оператор await применим к любому объекту, реализующему awaitable паттерн – опять же, никаких интерфейсов и базовых типов. LINQ-операторы тоже ожидают наличия методов .Select, .SelectMany, .Where и других. Ну и в дополнение ко всему, вроде бы во всех упомянутых сценариях это могут быть как extension-методы, так и «обычные».
Утверждение о том, что статические классы и члены классов не поддерживают полиморфизм в целом, не совсем корректно. C# разрешает ad hoc и параметрический полиморфизм для «статики».
Когда-то я бросался в крайности. Теперь я продолжаю бросаться в крайности.
Крайне плохие или крайне хорошие решения и подходы встречаются не столь часто. Почти всё, с чем мы сталкиваемся, находится где-то между чёрным и белым. Но автор почему-то в упор отказывается это признавать.
Соглашусь в этом с Вами, разделение прав доступа по типу операций имеет свои преимущества. Однако не все операции можно выразить в терминах CRUD, а поддержка двух независимых множеств T (тип операции) и R (ресурс) означает существование некоторых пар (T, R), которых наша доменная область не предусматривает.
Но в данном случае, как и всегда, стоит сперва тщательно проанализировать требования и выбрать наиболее подходящую для задачи модель.
По поводу атрибутов — конечно же, можно так сделать, но если для некоторого controller action-а мне надо было указать несколько permissions, то я мог их записать в одном атрибуте. Если мне надо несколько claims, то придётся помечать метод соответствующим числом атрибутов. Разница не столь существенная, но первый вариант выглядит более компактно и приятно.
А что Вы можете сказать по поводу permission-based системы безопасности? Ну т.е. когда у нас вместо claim (например, ресурс — Пользователь, действие/claim type — Создать, Удалить, и т.д.) есть простые идентификаторы (например, СоздатьПользователя). Мне кажется, что разница между ними не столь значительна, за исключением того, что в базовой библиотеке уже есть некая реализованная модель, завязанная на claims.
Лично мне она импонирует простотой интеграции с ASP.NET MVC при помощи action filters. Если мы хотим, чтобы действие Index у контроллера Projects было доступно только некоторым пользователям, то мы помечаем это действием самописным атрибутом [RequiresPermissions(Permissions.ReadProjects)], а конкретным пользователям назначаем полномочие ReadProjects.
Во время авторизации запроса экземпляр IPrincipal подменяется нашей собственной реализацией, которая запрашивает из БД набор полномочий для текущего IIdentity. Далее сравниваем полномочия пользователя и полномочия, запрошенные controller action-ом.
Хочу отметить, что я не пытаюсь сравнить роли с permissions/claims, они предоставляют идеологически разные модели обеспечения безопасности.
Например bandcamp.com. К сожалению, у меня нет данных по эффективности донейшненов, но знаю достаточное количество групп, которые свой материал публикуют именно там.
Приложение получилось довольно хорошим, но есть несколько замечаний.
Первое — производительность. Скроллинг панорамы заметно тормозит. Проверьте показатели FPS для compositor thread и fill rate. Навигация с какого-нибудь экрана обратно на главную страницу также занимает довольно много времени. Вероятно, какой-нибудь «тяжёлый» код выполняется в OnNavigatedTo/OnNavigatingFrom.
Второе — отступы в разделе «кино!» на стартовой панораме. Можно заметить, что у заголовка и контента разный margin слева. Стандартное значение — 24 пикселя
Ну и размер самих элементов меню на этой же странице можно было бы сделать чуть больше. Свободное место есть, да и попасть пальцем в нужный пункт было бы проще. Посмотрите например как это сделано в стандартном приложении marketplace.
Не пинайте за длинный комментарий. Надеюсь он поможет сделать приложение ещё лучше.
Стоит ещё отметить, что методы, включающие в себя yield-конструкции, могут возвращать не только IEnumerable, но и IEnumerator. При этом конечные автоматы, генерируемые компилятором, немного отличаются. Подробности можно почитать здесь — csharpindepth.com/articles/chapter6/iteratorblockimplementation.aspx
Подобные мобильные приложения выглядят не очень приятно на фоне нативных. К тому же зачастую в угоду кросс-платформенности нарушается рекомендованная гайдлайнами модель навигации (то, что отлично работает на iOS, например, оказывается непривычным для wp7). Непосредственно в данном случае — кнопка Home и Back/Forward на application bar. Писать для каждой платформы отдельную версию сайта — занятие глупое. Почему бы тогда уже не использовать нативные средства разработки? За статью спасибо.
Спасибо за статью.
Небольшое, но важное замечание (хоть и не связанное с основной темой) — использовать new Thread(..).Start() очень-очень не рекомендуется. Посмотрите в сторону ThreadPool.QueueUserWorkItem или System.Threading.Tasks (TPL на wp7 недоступен «из коробки», но есть хороший порт с Mono)
Я бы посоветовал установить стандартные значения отступа для контента (12 от левого и правого краёв). Скриншоты #2 и #3 не очень соответствуют общепринятому стилю
На самом деле, всё зависит от контекста, в которой решается данная задача. Автор _почти_ прав насчёт избыточности абстракций для вычисления факториала. Но есть, как минимум, одна ситуация, в которой был бы оправдан изложенный в статье подход — если всё это часть какой-либо математической библиотеки, где вполне имеет смысл использование различных реализаций. Хотя и в этом случае, я, пожалуй, не стал бы злоупотреблять фабриками алгоритмов вычисления факториалов.
И да, не стоит бросаться в крайности. Избыточность слоёв абстракции, ровно как и полное их отсутствие — зло. Путь добра, как всегда, посередине
>> Считается большим злом иметь код в xaml.cs файле.
Вы не совсем правы. MVVM — лишь концепция/рекомендация, а не строгое требование. Бездумно следовать каким-то принципам столь же глупо, как и отвергать существующие распространённые практики.
Нет ничего страшного в наличии определённой логики в codebehind-файлах — как правило, логики, связанной непосредственно с самим UI, которую не удалось описать (или это не столь эффективно) с помощью Actions/Behaviors/Triggers. Хотя это всего лишь одно из мнений. У каждого «свой» mvvm
Попробуйте ещё xsd.exe из .net sdk (позволяет сгенерировать классы по xml-документу или xsd-схеме, к ним уже можете применить описанный выше XmlSerializer).
Здесь небольшой референс по использованию: msdn.microsoft.com/en-us/library/x6c1kb0s(v=VS.100).aspx
Можете сохранить себе кучу времени при разборе большого числа сложных xml-документов. Но не забывайте, что кодогенерация — не всегда добро.
Это не совсем верно. Структурная типизация поддерживается в очень ограниченных масштабах. Например, в foreach итерируемый объект должен иметь метод
GetEnumerator, возвращающий объект с методомMoveNextи свойствомCurrent. Операторawaitприменим к любому объекту, реализующему awaitable паттерн – опять же, никаких интерфейсов и базовых типов. LINQ-операторы тоже ожидают наличия методов.Select,.SelectMany,.Whereи других. Ну и в дополнение ко всему, вроде бы во всех упомянутых сценариях это могут быть как extension-методы, так и «обычные».Крайне плохие или крайне хорошие решения и подходы встречаются не столь часто. Почти всё, с чем мы сталкиваемся, находится где-то между чёрным и белым. Но автор почему-то в упор отказывается это признавать.
Но в данном случае, как и всегда, стоит сперва тщательно проанализировать требования и выбрать наиболее подходящую для задачи модель.
По поводу атрибутов — конечно же, можно так сделать, но если для некоторого controller action-а мне надо было указать несколько permissions, то я мог их записать в одном атрибуте. Если мне надо несколько claims, то придётся помечать метод соответствующим числом атрибутов. Разница не столь существенная, но первый вариант выглядит более компактно и приятно.
Лично мне она импонирует простотой интеграции с ASP.NET MVC при помощи action filters. Если мы хотим, чтобы действие Index у контроллера Projects было доступно только некоторым пользователям, то мы помечаем это действием самописным атрибутом [RequiresPermissions(Permissions.ReadProjects)], а конкретным пользователям назначаем полномочие ReadProjects.
Во время авторизации запроса экземпляр IPrincipal подменяется нашей собственной реализацией, которая запрашивает из БД набор полномочий для текущего IIdentity. Далее сравниваем полномочия пользователя и полномочия, запрошенные controller action-ом.
Хочу отметить, что я не пытаюсь сравнить роли с permissions/claims, они предоставляют идеологически разные модели обеспечения безопасности.
Первое — производительность. Скроллинг панорамы заметно тормозит. Проверьте показатели FPS для compositor thread и fill rate. Навигация с какого-нибудь экрана обратно на главную страницу также занимает довольно много времени. Вероятно, какой-нибудь «тяжёлый» код выполняется в OnNavigatedTo/OnNavigatingFrom.
Второе — отступы в разделе «кино!» на стартовой панораме. Можно заметить, что у заголовка и контента разный margin слева. Стандартное значение — 24 пикселя
Ну и размер самих элементов меню на этой же странице можно было бы сделать чуть больше. Свободное место есть, да и попасть пальцем в нужный пункт было бы проще. Посмотрите например как это сделано в стандартном приложении marketplace.
Не пинайте за длинный комментарий. Надеюсь он поможет сделать приложение ещё лучше.
Небольшое, но важное замечание (хоть и не связанное с основной темой) — использовать
new Thread(..).Start()очень-очень не рекомендуется. Посмотрите в сторону ThreadPool.QueueUserWorkItem или System.Threading.Tasks (TPL на wp7 недоступен «из коробки», но есть хороший порт с Mono)И да, не стоит бросаться в крайности. Избыточность слоёв абстракции, ровно как и полное их отсутствие — зло. Путь добра, как всегда, посередине
Вы не совсем правы. MVVM — лишь концепция/рекомендация, а не строгое требование. Бездумно следовать каким-то принципам столь же глупо, как и отвергать существующие распространённые практики.
Нет ничего страшного в наличии определённой логики в codebehind-файлах — как правило, логики, связанной непосредственно с самим UI, которую не удалось описать (или это не столь эффективно) с помощью Actions/Behaviors/Triggers. Хотя это всего лишь одно из мнений. У каждого «свой» mvvm
Здесь небольшой референс по использованию: msdn.microsoft.com/en-us/library/x6c1kb0s(v=VS.100).aspx
Можете сохранить себе кучу времени при разборе большого числа сложных xml-документов. Но не забывайте, что кодогенерация — не всегда добро.