(… много воды утекло с тех пор… попалось в поисках про строки… так вот по теме сообщения...) По мне все варианты визуального программирования, будь то UI или DB, хороши с точки зрения посмотреть в целом, что получилось наваять. Но, в конце концов, если сбросить сгенерированное любым способом в тестовую базу данных, то потом можно вывести диаграмму любым относительно полнофункциональным ER-средством, коих нынче немало. Аналогично и для кода вряд ли проблема каким-нибудь CASE-средством вывести диаграмму. А если нужно что-то подправить, по мне всяко лучше править код, хоть в XML, хоть в SQL, хоть в C#. Во-первых чаще всего быстрее. Во-вторых, визуальные редакторы могут и всякого наворотить, и комментарии после их воздействия могут неожиданно исчезать, и прочие подобные неожиданности. Ну и в третьих, и, пожалуй, главное, как в каком б то ни было VCS результаты визуального редактирования будут выглядеть.
Было дело, я выбирал model first ради mapping'а хранимых процедур, а вот ради диаграммы — по мне странная причина.
По мне хорошо, если их наконец-то объединят, лишь б не криво. А то до сих .Net по большей части потенциально межплатформенный. А уж сколько проблем было с Mono начиная от низкой производительности заканчивая разной обработкой одного и того ж кода, хоть чаще и такого кода, какой писать не следует. И ещё было частое отставание, когда под Windows новые возможности уже есть, в Mono ещё только в разработке: хоть те ж PCL, можно сказать основа полноценной межплатформенности, Xamarin стали поддерживаться на год с лишним позже. Причём часто в portable subset что-то не попадало из-за странных решений Microsoft, хоть тот ж System.Security namespace для WinStore-приложений зачем-то сделали иначе, а в итоге в соответствующих профилях PCL не было даже элементарного вычисления hash'а. Главное, чтоб теперь хоть в Microsoft принимали разумные решения по таким вопросам.
Причина, по которой по мне в этой новости хорошего мало. Дай Бог, если они сумеют больше раскрутить эти инструменты, но могут, наоборот, загубить хорошее начинание. Самое странное, если они (Microsoft) хотят всё ещё называть себя лидером, хотя какое уж там нынче. Притом, что потенциально многие технологии лучше существующих аналогов в отличие от прежних времён, но вот с реализацией всё как-то не очень.
Во ViewModel у меня тоже (и в контроллере в случае iOS и т. п.). Но там у меня обычно как раз async void-методы, в них и вызываются всякие OnPropertyChanged в UI-потоке после вызова async Task-метода без ConfigureAwait. А использование ConfigureAwait(false) у меня в модели данных и далее.
Думаю, это решит многие задачи, по крайней мере я почти везде так пишу в async Task-методах, просто await обычно лишь в async void-методах. Как я в своё время специально проверял,
await operation
всегда и сразу приводит к возврату в поток SynchronizationContext, если он есть, а какой смысл делать эти переключения в тех классах, что отделены от пользовательского интерфейса? Я полагаю, что нагрузку на UI-поток нужно минимизировать (о чём особенно Android любит напоминать), так что как только ушли от взаимодействия с пользовательским интерфейсом, в диспетчеризации потоков лучше не использовать SynchronizationContext, а вернуться к нему непосредственно перед выдачей результатов пользователю.
«Многообещающий проект на codeplex» имеет одну главную проблему — автор не находит времени им заниматься (сюда вот я тоже только что заглянул). А что не сработало, прошу написать в ЛС, мне интересно, ибо мне тогда запустить удавалось.
В той идее мне не понравилось лишь одно — отсутствие portable-части, т. е. для iOS уже был б полностью отдельный модуль, но создал я его, когда официального SDK на .Net вообще не было. Идея «переписать, основываясь на .NET SDK для Windows Phone» у меня возникла, когда я увидел, что таковой стали делать. В последнее время я мало следил за его развитием, а основной моей идеей было выделить PCL с профилем 111 (или 259). За проект уровня этой статьи мне с моими темпами, понятное дело, браться было бессмысленно.
На нём пример front-end'а в приведённых по ссылке исходниках, хотя, конечно, можно сказать и что напрямую с рассмотренной темой Xamarin.Android не связан.
На мой взгляд это подробное рассмотрение одного из возможных примеров, чем оператор await лучше — что переключение контекста происходит не где случайно получилось, а только там, где оно нужно, притом это определяется на самом «глубинном» уровне, на котором нужность переключения контекста известна лучше всего. И при этом для верхних уровней обеспечивается полная абстракция, обеспечивающая независимость от конкретных железа и ОСей.
Не знаю, как было на момент написания статьи, но сейчас, мне кажется, с версией WindowsAzure.MobileServices 1.2.1 (как на screenshot'е) он не сработает, требуется WindowsAzure.MobileServices 1.3, который пока что только beta2. Да и класс MobileServiceLocalStore, от которого наследуется текущая версия MobileServiceSQLiteStore, входит только в версию 1.3. Впрочем, подождём release-версий и того, и другого, тогда уж будет всё определённо.
А вот если dispose'ить всякие data access layer, service layer и прочие, инициируя из наблюдаемого объекта (предположим, что приложение спроектировано без перекрёстного наблюдения и прочих кривых решений) с потокобезопасным завершением всех действий. Т. е. начали dispose'ить, после этого новые действия, в т. ч. генерирование событий, не начинаем, но ждём завершения уже начатых. При этом наблюдаемый объект остальные (вроде service layer) создаёт и удаляет, для остального возможны события и прочие callback'и. Но если завершить все вызовы перед тем, как начать удалять всякие наблюдающие объекты, то и событию будет вызваться неоткуда. Т. е. если, например, новое remote-уведомление поступит в момент dispose, наблюдаемый объект при его обработке вернёт обрабатываемую ошибку, что он уже начал dispose'иться и новых вызовов не принимает. В случае разработки toolkit'а для стороннего использования это, конечно, не реализовать (да и вообще, по-моему, сложно защитить от кривого использования), но для end user-проектов вроде как решение. Поправьте, если где ошибаюсь.
Вроде у них (Xamarin) есть (или были) специальные тарифы для некоммерческого использования (но найти на Web-узле их, кстати, не очень просто), но и те небесплатные (кроме упомянутого варианта с ограничением на размер компилируемого кода). Но вот интересно, что они, похоже, постепенно растождествляются с проектом Mono, уже и в названиях сборок и т. п. появляется название Xamarin вместо Mono — не означает ли это, что какой-то старый вариант станет бесплатным для некоммерческого использования с меньшими ограничениями как часть проекта Mono — может кто случаем в курсе их планов?
Было дело, я выбирал model first ради mapping'а хранимых процедур, а вот ради диаграммы — по мне странная причина.
В той идее мне не понравилось лишь одно — отсутствие portable-части, т. е. для iOS уже был б полностью отдельный модуль, но создал я его, когда официального SDK на .Net вообще не было. Идея «переписать, основываясь на .NET SDK для Windows Phone» у меня возникла, когда я увидел, что таковой стали делать. В последнее время я мало следил за его развитием, а основной моей идеей было выделить PCL с профилем 111 (или 259). За проект уровня этой статьи мне с моими темпами, понятное дело, браться было бессмысленно.