Насчет var — дело привычки. Обычно отторжение такой синтаксис вызывает только у тех кто долгое время писал на С/С++, со временем привыкают. Читаемость это нисколько не ухудшает если код написан нормально.
И вот 100% не надо typedef, вреда от него будет больше чем пользы. Если имя типа получается слишком сложным то проблема решается вовсе не синтаксическими костылями. Переименуйте тип, создайте новый итд итп. И не используйте вложенные generic-и где ни попадя, и проблемы не будет.
Если же вам нужен просто интерфейс который можно динамически строить на каком-то декларативном языке, так тот же XAML, XUL, QML
Ну для .NET из коробки только XAML. Все остальное с костылями и следовательно заранее неизвестным количеством граблей на которые придется наступить. В этом плане на фоне прочих 'неродных' решений HTML пожалуй будет предсказуемее что ли. А так, теоретически, к примеру при наличии в проекте веб-частей, возможно использование суммарно на одну технологию меньше перекрыло бы 'не лучшесть' этого варианта.
Но в любом случае я согласен что что-либо серьезное пока только на сторонних движках можно делать, ибо всегда чем меньше приложение зависит от внешних факторов тем лучше.
Вы либо абсолютно не знаете что такое WPF Browser Applicaiton либо не поняли идею статьи.
WPF Browser Applicaiton не заворачивается в html, такое приложение загружается браузером и запускается в отдельном процессе PresentationHost.exe, просто parent-окном является браузер. На такой «странице» с этим xbap-приложением HTML отсутствует в принципе.
То что вы советуете диаметрально противоположно сути статьи. Суть — рисовать UI десктопного приложения на HTML _вместо_ XAML или WinForms, и встраивать в приложение браузер для его отрисовки. Подчеркну — десктопное приложение, с полными возможностями десктопных приложений и без неободимости использовать к-л сервера. Вы же советуете взять «десктопное» приложение с десктопной технологией UI (xaml ни в какой html при выполнении не трансформируется) и запихнуть его тем самым в браузер, причем непонятно зачем, поскольку никаких преимуществ по сравнению с обычным wpf приложением при использовании в качестве standalone-приложения это не даст, зато на ровном месте получаем кучу ограничений песочницы в которой оно выполняется и которые еще руками отключать придется.
Да, я читал об этом. Но считаю что по возможности лучше обходиться без записей в чужие/системные ключи реестра когда это возможно. Раз тег тоже решает проблему, то реестр можно не трогать. Но ключ реестра поможет при отображении не собственного текста из памяти а какой-то реальной веб-страницы из интернета, на содержимое которой повлиять невозможно.
Json вполне сишарпабельный, пишем класс настроек и сериализуем/десериализуем его в файл через стандартный DataContractJsonSerializer или проверенной временем сборкой Newtonsoft.Json
Но тут есть один баг в компоненте, который читает ini-файл. Он кроказаблит пути с кириллицей и исключает их из наблюдения. Пока не знаю как победить.
Очень просто — не используйте ini, тем более в виде кривых сторонних индусских библиотек. Что за мракобесие в самом деле, чем стандартный app.config не угодил?
В точку. Все знакомые, от кого слышал восторженные отзывы о сериале, книгу как выясняется при этом не читали. Меня хватило то ли на одну то ли на две серии.
Угу, если заранее не знать что это шрифт яндекса то при беглом взгляде обычного человека на рекламу например никакого фирменного стиля тут не прослеживается, ну шрифт как шрифт, такой же как и везде. За исключением криво обкусанных 6 и 9.
При этом все эти их критерии про «умность» шрифта и «технологичность с человеческим лицом» по моему выглядят больше как разглагольствования аудиофилов о нематериальных сущностях в проводах.
Экономия ресурсов на операторах инкремента это конечно лол.
Надо полагать авторы имели ввиду что теоретически могут быть косяки из за незнания приоритета операторов если инкремент внутри сложного выражения, это вроде нередкая ошибка. Но имхо инкремент/декремент гораздо нагляднее всегда отдельным выражением делать а не запихивать в какие то сложные выражения. Это во-первых куда читаемее, а во-вторых постфиксный оператор хотя бы не так мерзко выглядит как префиксный.
3 года назад выбирал нормальный ноут для работы. Главными критериями были — i7, малый вес, нормальная клавиатура, нормальный ips, наличие или возможность установки ssd, хотя бы минимальный видеоадаптер от nvidia и отсутствие проблем с перегревом при долгой нагрузке. В итоге прошел мимо и ленов и макбуков, ибо выбор пал на sony svs1513 обладающий после некоторого апгрейда максимальным набором преимуществ перед остальными. Как бонус еще нормальный внешний вид, металлический корпус и грамотная конструкция в виде мелочей вроде забора воздуха сбоку а выдува назад. Поставил туда ssd intel на 480гб, hdd на 2 терабайта (правда пришлось поискать тонкий) и расширил ram до 12Гб, докупил дополнительный внешний аккумулятор и док станцию в которой еще один hdd. Жаль что они свернули производство ноутов, топовые модели были реально интересными.
Зато хороший пример как не надо рисовать UI программы. Более ужасного дизайна так с ходу даже и не вспомнить. Блин, да даже если наспех на коленке рисовать так не получится, это же надо специально делать криво.
Во-первых я никому ничего не навязывал. Во-вторых не каждая система подразумевает наличие сторонних клиентов. В-третьих я не конкретизировал какое именно исключение должен бросать wcf сервис, или вы считаете что я разглагольствую об исключениях в wcf-сервисах не зная о существовании FaultException? В-четвертых даже любое абстрактное исключение при желании можно обернуть в FaultException, это лишь вопрос конкретной реализации и сути не меняет поскольку речь о том что в итоге бросается именно исключение и именно при ожидаемом поведении и это допустимо и адекватно.
Такое впечатление что вы пишете просто чтобы потроллить. Я просто привел пример где бросок исключения для той же валидации вполне уместен и корректен, а своими знаниями по mvc трясите пожалуйста перед кем нибудь другим, я пока приводил в пример только wcf, если с чем то конкретно несогласны пишите по существу.
В целом стандартные .net механизмы по сути тоже через уведомления ошибки собирают, фактически в статье велосипед. Я к тому что сбор ошибок через уведомления в итоге не противоречит использованию исключений для выдачи суммарного результата проверки наружу, а подход 'использовать исключения только если в программе что то пошло не так как задумано', т.е. практически отказываться от них вообще, мне кажется несколько ограничен и приводит к большому количеству велосипедов.
Допустим есть некий wcf-сервис, и в нем метод на вход принимает объект с параметрами, на выход выдает объект с данными. Вполне нормально будет после валидации бросить исключение со списком ошибок, не городить же быдлокод из ненужного класса-обертки с самим объектом и коллекцией ошибок валидации, вполне нормально будет кинуть исключение, а на клиенте уже вытаскивать список ошибок из этого исключения в обработчике.
И вот 100% не надо typedef, вреда от него будет больше чем пользы. Если имя типа получается слишком сложным то проблема решается вовсе не синтаксическими костылями. Переименуйте тип, создайте новый итд итп. И не используйте вложенные generic-и где ни попадя, и проблемы не будет.
Anonymous types незаменимы в linq например.
Ну для .NET из коробки только XAML. Все остальное с костылями и следовательно заранее неизвестным количеством граблей на которые придется наступить. В этом плане на фоне прочих 'неродных' решений HTML пожалуй будет предсказуемее что ли. А так, теоретически, к примеру при наличии в проекте веб-частей, возможно использование суммарно на одну технологию меньше перекрыло бы 'не лучшесть' этого варианта.
Но в любом случае я согласен что что-либо серьезное пока только на сторонних движках можно делать, ибо всегда чем меньше приложение зависит от внешних факторов тем лучше.
WPF Browser Applicaiton не заворачивается в html, такое приложение загружается браузером и запускается в отдельном процессе PresentationHost.exe, просто parent-окном является браузер. На такой «странице» с этим xbap-приложением HTML отсутствует в принципе.
То что вы советуете диаметрально противоположно сути статьи. Суть — рисовать UI десктопного приложения на HTML _вместо_ XAML или WinForms, и встраивать в приложение браузер для его отрисовки. Подчеркну — десктопное приложение, с полными возможностями десктопных приложений и без неободимости использовать к-л сервера. Вы же советуете взять «десктопное» приложение с десктопной технологией UI (xaml ни в какой html при выполнении не трансформируется) и запихнуть его тем самым в браузер, причем непонятно зачем, поскольку никаких преимуществ по сравнению с обычным wpf приложением при использовании в качестве standalone-приложения это не даст, зато на ровном месте получаем кучу ограничений песочницы в которой оно выполняется и которые еще руками отключать придется.
Очень просто — не используйте ini, тем более в виде кривых сторонних индусских библиотек. Что за мракобесие в самом деле, чем стандартный app.config не угодил?
При этом все эти их критерии про «умность» шрифта и «технологичность с человеческим лицом» по моему выглядят больше как разглагольствования аудиофилов о нематериальных сущностях в проводах.
Иногда можно неплохо сэкономить на доставке если много мелких посылок например, да и обычно это быстрее чем почтой.
Надо полагать авторы имели ввиду что теоретически могут быть косяки из за незнания приоритета операторов если инкремент внутри сложного выражения, это вроде нередкая ошибка. Но имхо инкремент/декремент гораздо нагляднее всегда отдельным выражением делать а не запихивать в какие то сложные выражения. Это во-первых куда читаемее, а во-вторых постфиксный оператор хотя бы не так мерзко выглядит как префиксный.
Такое впечатление что вы пишете просто чтобы потроллить. Я просто привел пример где бросок исключения для той же валидации вполне уместен и корректен, а своими знаниями по mvc трясите пожалуйста перед кем нибудь другим, я пока приводил в пример только wcf, если с чем то конкретно несогласны пишите по существу.
Допустим есть некий wcf-сервис, и в нем метод на вход принимает объект с параметрами, на выход выдает объект с данными. Вполне нормально будет после валидации бросить исключение со списком ошибок, не городить же быдлокод из ненужного класса-обертки с самим объектом и коллекцией ошибок валидации, вполне нормально будет кинуть исключение, а на клиенте уже вытаскивать список ошибок из этого исключения в обработчике.