Сахарные инжекции в C#

Стараюсь внимательно относиться к терминам.

Инжекции — это инженерный термин, близким переводом которого с английского является внедрение. О смысловых оттенках можно спорить долго, но существует такое понятие как инжектор — механизм или приспособление для внедрения чего-либо. В технической области это слово чаще употребляется, чем, скажем, инъектор или внедритель и звучит благозвучно, а также наиболее созвучно с английским написанием, поэтому выбор пал именно на понятие инжекции.

Декларировать, декларация чего-либо достаточно часто встречаются в документации для разработчиков.

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

Спасибо, что следите за чистотой языка, это тоже важно!

Сахарные инжекции в C#

Смутно припоминаю, что у меня как раз и была ситуация, когда обычный operation.Result не работал, поэтому пришлось создавать новый таск. Хотя в большинстве случаев хватит первого варианта, второй также стоит взять на заметку.

Сахарные инжекции в C#

Интересная ссылка про монады. Правда, непривычный синтаксис иногда получается, хотя в некотрых случаях выглядит красивее обычного.

Ох, перемудрил немного с Await, да, достаточно operation.Result :) Спасибо, что исправили!

Сахарные инжекции в C#

Соглашусь с тем, что у начинающего программиста может вызвать вопросы наличие двух альтернативных конструкций, выполняющих по сути одно и тоже. Но стоит всё же признать, что в плане красоты и лаконичности кода ForEach-расширение иногда смотрится выгоднее.

Инжекторы контекста xaml

Всё, что нужно, давно реализовано. Не нравится — не пользуйтесь.

Инжекторы контекста xaml

На той кнопке под скролом — нет.

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

Ctrl-С/Ctrl-V? Понимаю.

Ну, если это все комбинации, что вы знаете, то рекомендую изучить и другие.

И если на вашем компьютере не хватает ресурсов, чтобы комфортно работать с редактором, то советую задуматься над модернизацией машины. У множества других людей всё превосходно работает.

Справедливости ради, я не «всё критиковал», я другие статьи полистал, там, кроме выдумывания собственных велосипедов (Selfish Bike, ага), ничего особенно плохого.

Хорошо, что полистали. Пользуйтесь велосипедами на здоровье. Или не пользуйтесь из принципа, ваше личное дело.

Инжекторы контекста xaml

Вы поражаете своей невнимаельностью и поверхностностью. Drag&Drop превосходно работает во всех отношениях, да и все базовые хоткеи есть.

В плане обработки текста, действительно, редактор сравним с VS по функционалу. Конечно, в нём нет функций решарпера, что-то сделано лучше, что-то хуже, но, к примеру, работа с регулярными выражениями организована даже на более продвинутом уровне.

Впрочем, памяти оно теперь выжрало больше студии. Так что я пойду…

Боюсь только, что студия заняла далеко не 30 Кб. Но вы смело можете отправляться гордиться вашей «победой»:) Успехов!

P.S. Извиняйте, если где-то был резок с вами, просто вы так упорно всё критиковали, что это нельзя было оставить без внимания.

Инжекторы контекста xaml

ох… AvalonDock не достаточно взять, что бы называться аналогом студии.
Ну раз уж назвались груздем… И где же у вас пипка над скролом, которая делит экран на 2?

Поищите её под скроллом… И делит она экран на 2, на 3 и так далее, чего даже нет в VS. Съели?))

Да и вообще, раз уж мы в третьем лице говорим, автору стоит оставить другим людям судить на сколько информация полезна или вредна.

Так каждый за себя и решит. А вы не отвечайте за всех.

Инжекторы контекста xaml

Вы чувствуете вообще разницу между native и managed кодом?

Да, в техническом плане функционал редактирования и просмотра текста аналогичен тому, что в Visual Studio и реализован грамотно, поэтому сравнение будет справедливым. Извините, но ваши суждения обнажают ваше дилетанство в этой области, ничего личного, просто как .NET-разработчик, имеющий немалый опыт, знаю, что говорю.

Пользоваться редактором или нет вы решаете сами. Это же касается и фреймворка. Не знаю, что вас так зацепило, и откуда столько негатива в адрес автора статьи, когда в ней он делится действительно полезной информацией с другими людьми.

Инжекторы контекста xaml

Для чистоты эксперимента отключите также в редакторе функции проверки орфографии и автодополнения слов, поскольку они требовательны к памяти, после чего уже можно конструктивно критиковать приложение, сравненивая с аналогичными решениями в техническом плане.

Инжекторы контекста xaml

Во-первых, если вы ещё не поняли, никто ничего не впаривает. У каждого своя голова на плечах, и каждый самостоятельно решит, что использовать.

Во-вторых, если вы так смело называете приложение студенческой поделкой, то откройте ваш файлик в редакторе Visual Studio и сравните результаты. Это будет более объективно. Или редактор Visual Studio, по-вашему, тоже относится к разряду студенческих поделок?

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

Инжекторы контекста xaml

Спасибо, что сказали о нерабочей ссылке, иногда с One Drive бывают какие-то проблемы.
Попробуйте ещё раз (Aero Framework).

Ну вот осталось понять как вы это без сервис локатора(у вас это Storage, напомню) предлагаете делать?

Элементарно, в расширении разметки вы указываете произвольный ключ, а затем по нему достаёте вью-модель из контейнера или создаёте новую по определённым правилам, как вам нужно.

Я тут ваш блокнотик запустил. Он на голом скролинге тысячи строчек выжрал 50 мб памяти за минуту.
Нечем тут хвастаться.

Для современных систем это адекватная цифра, тем более для .NET приложения, где сборщик мусора уже изначально резервирует некоторое количество памяти у системы. Более того, совершенно пустое WPF приложение уже занимает в памяти около 7-10 Мб, поэтому 50 Мб для полноценного редактора хороший результат, и, стоит признать, ваша критика здесь всё-таки не конструктивна. Да и применение библиотеки далеко не ограничивается одним лишь редактором.

Инжекторы контекста xaml

Начнём с того, что код библиотеки полностью открыт и ничто не мешает вместо Service Locator использовать любой другой шаблон проектирования на ваш выбор.

Большинство современных unity-контейнеров реализуют Service Locator, но значимость состоит не в том, что Aero Framework предлагает его использовать по умолчанию, а в том, что в библиотеке введён принцип прямых инжекций, когда инжектировать вью-модель можно точечно в любое место визуального дерева.

Что касается вашего примера, то в статье предпологается, что в SettingsViewModel хранятся глобальные параметры для пользователя, как обычно и бывает в приложениях, но запросто можно использовать и динамически создаваемые вью-модели. Взгляните на пример к библиотеке: AppViweModel статическая, а TextViewModel нет, — и всё прекрасно работает.

Довелось написать немало завершённых приложений и никаких ощутимых проблем со всем этим не было ни разу. Решайте сами, использовать библиотеку или нет в вашей работе. На мой взгляд, основная её ценность в простоте и лаконичности получаемого кода, чего не хватало многим проектам, которые попадались автору на практике и использовали другие MVVM-фреймворки.

Инжекторы контекста xaml

Думаю, если вы хорошо подумаете над этим или другими каверзными вопросами, то и сами сможете на них ответить :)

Нет никакой проблемы в том, что вью-модель используется на нескольких представлениях сразу. Просто удалите её из unity-контейнера в нужный вам момент, например, при закрытии окон. Или опишите подробнее тот сценарий и трудности, которые не позволяют этого сделать…

Расширения привязки и xaml-разметки на примере локализации

У меня, похоже, находит инжекции, или вы что-то другое имеете в виду?



d:DesignInstance тоже работает и подсказки появляются.

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    d:DataContext="{d:DesignInstance viewModels:AppViewModel, IsDesignTimeCreatable=True}"

Расширения привязки и xaml-разметки на примере локализации

Попробуйте починить примерно так <Grid d:DataContext="{d:DesignInstance viewModels:AppViewModel}">, возможно, подсказки появятся (сам не пробовал, поскольку обхожусь без них).

А решарперовский Find Usages прекрасно работает и по умолчанию.

Расширения привязки и xaml-разметки на примере локализации

Про ограничения парсеров разметки на некоторых платформах упоминалось в статье. Соглашусь с тем, что в ряде случаев такой способ локализации теряет лаконичность и практическую ценность. Но тем не менее сам механизм расширений привязки сохраняет смысл, поскольку оставляет возможность реализации принципа прямых инжекций, который рассмотрен в следующей статье, и ряда других удобных усовершенствований.

Конечно, стоит признать многословность, но обычно интерфейс и разметка в мобильных Windows Store и Windows Phone 8.1 приложениях проще, чем на десктоп-платформах, поэтому на этот недостаток ещё можно закрыть глаза в виду тех преимуществ, которые можно реализовать.

Инжекторы контекста xaml

Стоит также упомянуть о том, что зачастую после загрузки представления возникает необходимость в обновлении каких-либо данных. Чтобы обойтись без бехаинд-кода в библиотеке Aero Framework предусмотрен механизм контекстных триггеров команд.

<View DataContext="{Store Key=viewModels:ProductsViewModel}">
    <Attacher.ContextTriggers>
        <ContextTrigger 
            EventName="Loaded" 
            UseEventArgsAsCommandParameter="False"
            Command="{Context Key=Refresh, StoreKey=viewModels:ProductsViewModel}"/>
    </Attacher.ContextTriggers>
...
</View>

public class ProductsViewModel : ContextObject, IExposable
{
    public Product CurrentProduct
    {
        get { return Get(() => CurrentProduct); }
        set { Set(() => CurrentProduct, value); }
    }

    public ContextSet<Product> Products { get; set; }

    public virtual void Expose()
    {
        Products = new ContextSet<Product>();
        
        this[() => CurrentProduct].PropertyChanged += (sender, args) => Context.Get("GoToProduct").RaiseCanExecuteChanged();
        
        this[Context.Get("GoToProduct")].CanExecute += (sender, args) => args.CanExecute = CurrentProduct != null;
        this[Context.Get("GoToProduct")].Executed += (sender, args) => Navigator.GoTo(args.Parameter);
        this[Context.Refresh].Executed += async (sender, args) =>
        {
            try
            {
                var products = await Bank.Current.GetProducts();
                CurrentProduct = null;
                Products.Clean();
                products.ForEach(p => Products.Add);
            }
            catch (Exception exception)
            {
                Error = Unity.App.Localize(exception.Message);
            }
        };
    }
}

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

Расширения привязки и xaml-разметки на примере локализации

Ещё на Windows Store и Windows Phone 8.1, к сожалению, допустим только такой вариант декларации из-за ограничений парсера разметки

<TextBlock>
    <TextBlock.Text>
        <local:Localizing Key=AppDescription>
    </TextBlock.Text>
</TextBlock>

Расширения привязки и xaml-разметки на примере локализации

Спасибо, немного позже посмотрю. По крайней мере, для WP8.1 расширения привязки у меня работали с префиксом local, то есть когда находились в основной сборке. Для WP7 и WP8 всё точно работает, это хорошо проверял.