Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Навигация на основе представлений (View-Based Navigation)

Несмотря на то, что навигация на основе состояний может быть полезна в сценариях, описанных ранее, тем не менее, навигация в приложении часто требует замены одного представления на другое. В Prism, такой вид навигации называется «навигация на основе представлений (view-based navigation)».

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

• Цель навигации — контейнер для добавляемых, или удаляемых представлений — может обрабатывать навигацию разными способами при добавлении и удалении представлений, или может визуализировать процесс навигации по-разному. Во многих случаях, целью навигации является обычный Frame, или ContentControl, и представления просто отображаются внутри этих элементов управления. Однако существует множество сценариев, когда целью навигации является другой вид элементов управления, таких как TabControl, или ListBox. В таких случаях, навигация может потребовать активации или выделения уже существующего представления, или добавление нового представления.
• Приложению часто будет требоваться, каким-либо образом идентифицировать представление, к которому должна быть выполнена навигация. Для примера, в web-приложениях, страница, к которой выполняется навигация, напрямую идентифицируется по URI. В клиентских приложениях, представление может быть идентифицировано по имени его типа, по расположению файла ресурсов, или множеством других способов. В составных приложениях, состоящих из слабо связанных модулей, представления зачастую определены в раздельных модулях. Отдельные представления, в таких случаях, должны иметь возможность быть идентифицированы без создания дополнительных зависимостей между модулями.
• После идентификации представления, процесс его создания и инициализации должен быть тщательно скоординирован. Это особенно важно при использовании паттерна MVVM. В таком случае, представления и соответствующая модель представления должны быть созданы и ассоциированы друг с другом во время совершения навигации. В случае использования контейнера внедрения зависимостей, такого как Unity, или MEF, при создании модели представления и/или представления может потребоваться использование особого механизма конструирования.
• MVVM паттерн позволяет отделить UI приложения от его логики взаимодействия с пользователем и бизнес-логики. Однако процесс навигации может охватывать как UI, так и логику приложения. Пользователь может начать навигацию внутри представления, в результате чего представление будет обновлено. Но часто будет требоваться возможность инициировать и скоординировать навигацию из модели представления. Важным аспектом для рассмотрения, является способность чётко разделить навигационное поведение между представлением и моделью представления.
• Приложению часто может потребоваться передавать параметры, или контекст, представлению для его корректной инициализации. Для примера, если пользователь производит навигацию к представлению для редактирования информации о выбранном клиенте, ID этого клиента, или его данные, должны быть переданы в представление, для отображения в нем корректной информации.
• Многим приложениям необходимо тщательно координировать навигацию для уверенности, что будут выполнены определённые бизнес-требования. К примеру, пользователю может быть показано всплывающее сообщение о некорректности введённых им данных, во время попытки навигации к другому представлению. Этот процесс требует координации между предыдущим и новым представлениями.
• Наконец, большинство современных приложений позволяют пользователю производить навигацию к предыдущему, или к следующему представлению. Аналогично, некоторые приложения реализуют свой рабочий процесс, используя последовательность представлений, или форм и позволяют пользователю производить по ним навигацию вперёд или назад, добавляя или редактируя данные, перед тем, как завершить задачу и отправить все сделанные изменения одним пакетом. Такие сценарии требуют некоторого механизма журналирования, для того, чтобы последовательность навигации могла быть сохранена, повторена, или предопределена.

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

Прим. перев.: это перевод статьи Six years of WPF; what's changed?, написанной 3 августа 2012 года. Сейчас WPF уже не шесть, а семь лет, однако ничего не изменилось.

До перехода в Octopus Deploy на полную ставку я провёл год за написанием на WPF системы оценки рисков для трейдеров в инвестиционном банке. До того я работал консультантом, по большей части фокусируясь на WPF. Последние шесть лет я жил и дышал технологией, и в этом посте я хочу поделиться некоторыми мыслями о прошлом и будущем WPF и XAML.

Шесть лет назад я написал статью про валидацию в WPF на Code Project. Ещё я написал свой error provider, который поддерживает IDataErrorInfo, потому что — вы не поверите! — WPF 3.0 не поддерживал IDataErrorInfo. Позже я работал над несколькими опенсорсными WPF проектами вроде Bindable LINQ (первоначального реактивного программирования для WPF, ещё до изобретения Rx) и Magellan (MVC для WPF а-ля ASP.NET). Я даже некоторое время состоял в клубе, посвящённому превозносению MVVM и киданию ссылок на Code Project, известном как WPF Disciples («Приверженцы WPF»).

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

Вот как в далёком 2006-м году выглядела разметка относительно простого окошка (код позаимствован из проекта, над которым я тогда работал):

	<Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
	  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
	  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
	  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
	  xmlns:system="clr-namespace:System;assembly=mscorlib"
	  Title="TrialBalance" 
	  WindowState="Maximized"
	  Width="1000"
	  Height="700"
	  Icon="{StaticResource Image_ApplicationIcon}"
	  Background="{StaticResource Brush_DefaultWindowBackground}"
	  x:Name="_this">

Только взгляните на все церемонии! x:Class! Пространства имён XML! Почему бы не объявить всё это в одном месте, почему бы стандартные пространства имён не включать неявно?

К счастью, сейчас 2013-й год, и WPF был проделан огромный путь. Вот так код будет выглядеть сегодня:

Этой первой статьей я бы хотел начать цикл переводов постов с замечательного блога, в котором Beatriz Costa детально объясняет определенные аспекты Binding'а в WPF. В первом посте затрагивается тема использования Binding'а без указания каких-либо дополнительных свойств.

Если вы разрабатываете приложения для XAML-based платформ, таких как WPF, Silverlight, Windows Phone, или Windows Store, то Prism, определённо, сильно поможет вам упростить их разработку. После создания нескольких проектов с использованием Prism, я убедился в работоспособности такого подхода и решил подготовить перевод официального руководства Prism. Итак, часть первая, что же такое Prism.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Prism является руководством, разработанным для того, чтобы помочь проектировать и создавать насыщенные, гибкие и легко поддерживаемые Windows Presentation Foundation (WPF) приложения, Silverlight Rich Internet Applications (RIAs), и программы под Windows Phone 7-8, а также Windows Store приложений. Используя паттерны проектирования, которые воплощают важные принципы архитектурного дизайна, такие как разделение ответственности (Separation of Concerns, SoC) и слабая связанность (Loose coupling), Prism помогает вам проектировать и писать приложения со слабо связанными компонентами, которые могут независимо развиваться и потом объединяться в одно целое с минимальными усилиями. Этот тип приложений известен как составные приложения.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Эта глава рассказывает о том, что нужно сделать для загрузки приложения Prism. Приложение Prism требует регистрации и конфигурации компонентов во время запуска – этот процесс известен как bootstrapping.

Что такое загрузчик (Bootstrapper)

Загрузчик является классом, ответственным за инициализацию приложения, созданного с использованием библиотеки Prism. При использовании загрузчика вы получаете больший контроль над тем, как компоненты библиотеки Prism создаются и соединяются при запуске вашего приложения. Библиотека Prism включает абстрактный базовый класс загрузчика, который может быть специализирован для использования с любым контейнером. Многие из методов в классах загрузчиков являются виртуальными. Можно переопределять эти методы для предоставления собственной их реализации.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

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

Для связи всех частей воедино, Prism приложения полагаются на DI контейнер. DI контейнеры уменьшают зависимости между объектами, предоставляя способ создания экземпляров классов и управления их временем жизни в зависимости от конфигурации контейнера. При создании объектов с помощью контейнера, он инжектирует в них необходимые зависимости. Если зависимости ещё не были созданы, то контейнер в начале создаёт их и разрешает их собственные зависимости. В некоторых случаях, сам контейнер внедряется как зависимость. Например, при использовании Unity, в модули внедряется контейнер для того, чтобы они могли зарегистрировать в нём свои представления и службы.

Есть несколько преимуществ использования контейнера:

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

В контексте приложения, основанного на библиотеке Prism, есть определённые преимущества использования контейнера:

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

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Паттерн Model-View-ViewModel (MVVM, модель-представление-модель представления) поможет вам отделить бизнес-логику и логику представления от пользовательского интерфейса. Поддержка разделения ответственности между логикой приложения и UI может сделать ваше приложение более лёгким для тестирования, поддержки и развития. Это может также значительно улучшить возможности повторного использования кода и позволит разработчикам и дизайнерам легче сотрудничать при разработке соответствующих частей приложения.

Используя паттерн MVVM, пользовательский интерфейс приложения, логика представления и бизнес-логика разделяются на три отдельных класса. Это представление, которое инкапсулирует UI и его логику, модель представления, которая инкапсулирует логику представления и её состояния, и модель, которая инкапсулирует бизнес-логику приложения и данные.

Prism включает примеры и образцы реализации, которые показывают, как реализовать шаблон MVVM в Silverlight или в WPF приложениях. Библиотека Prism также предоставляет функции, которые могут помочь реализовать данный паттерн. Эти функции воплощают наиболее распространённые методы для реализации паттерна MVVM и разработаны, чтобы обеспечить тестируемость и совместимость с Expression Blend и Visual Studio.

Эта глава даёт краткий обзор паттерна MVVM и описывает, как его реализовать. Глава 6 описывает, как реализовать более сложные сценарии MVVM, используя библиотеку Prism.

Есть люди, которым нравится писать .NET приложения. Есть люди, которые любят системы компьютерной алгебры. В этой статье круги Эйлера пересекутся!

Эксклюзивно для Хабра.



(кликабельно)

Продолжаем щупать нашими ненасытными пальчиками третий PowerShell. В прошлый раз мы сделали обзор новшеств и прикоснулись к нескольким дополнениям: попробовали командлет Show-Command, обкатали автоматическую подгрузку модулей, посмотрели на упрощенный языковой синтаксис и сконфигурировали файл сессии, попутно проделегировав пользователю сессии часть полномочий.

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

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial propertyеу
Is loop-free connectivity.
A tree that must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.
— Radia Joy Perlman

Все выпуски

6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование

В прошлом выпуске мы остановились на статической маршрутизации. Теперь надо сделать шаг в сторону и обсудить вопрос стабильности нашей сети.
Однажды, когда вы — единственный сетевой админ фирмы “Лифт ми Ап” — отпросились на полдня раньше, вдруг упала связь с серверами, и директора не получили несколько важных писем. После короткой, но ощутимой взбучки вы идёте разбираться, в чём дело, а оказалось, по чьей-то неосторожности выпал из разъёма единственный кабель, ведущий к коммутатору в серверной. Небольшая проблема, которую вы могли исправить за две минуты, и даже вообще избежать, существенно сказалась на вашем доходе в этом месяце и возможностях роста.

Итак, сегодня обсуждаем:

• проблему широковещательного шторма
• работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
• технологию агрегации интерфейсов и перераспределения нагрузки между ними
• некоторые вопросы стабильности и безопасности
• как изменить схему существующей сети, чтобы всем было хорошо

Несколько лет назад после прочтения матрицы компетентности программиста я поискал аналогичную матрицу для системных администраторов. Ближашее что я тогда нашел это Sage Level Job Descriptions, но меня не оставляло желание составить для системных администраторов аналогичную таблицу.

Я несколько раз начинал это делать, потом бросал и снова начинал, и только теперь наконец-то сделал:

Вступление

Я думаю, что многие веб-разработчики задают себе вопрос о том, как передать пользователю какое-либо сообщение, напоминание. Раньше для этого было необходимо постоянно отправлять запросы к веб-серверу, но теперь появилась такая удобная технология, как Web Socket.

В этой статье я хочу показать, как можно написать простой чат на ASP.NET MVC 4 с помощью Web Socket.

Разрабатывая приложения, мы постоянно сталкиваемся с новыми подходами, языками и концептами. И постоянно мы мечемся в сомнениях «смогу ли я быть на волне, оставаться конкурентоспособным, учитывая все изменения и тренды?». Давайте задумаемся на мгновение, вспомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.

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

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.

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

IL Stub Diagnostic Tool

IL заглушки (stubs) динамически генерируются во время работы приложения на лету и управляют маршаллингом и вызовом целевого метода. IL Stub Diagnostic tool была создана чтобы улучшить качество отладки приложений. Это real-time монитор, который показывает детали каждой IL заглушки, создаваемой в исследуемом процессе. Для каждой заглушки утилита показывает ее IL код и сигнатуры Managed/Unmanaged методов

Хабраприветствую всех, кому интересна эта тема.

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

Как известно, в .NET память делится на две категории: стек (Stack) и управляемая куча (managed heap, далее просто куча). На стеке располагается ссылка(ObjectRef) на объект (ObjectInstance), который, в свою очередь, располагается в куче.

В данной статье речь пойдет о расположении объекта в куче.

Предполагается, что у читателя имеются знания о:
1. stack
2. managed heap
3. GC
4. Слабые ссылки (weak references)

Не так давно на Хабре была опубликована статья (ссылка на топик) моего коллеги AlexanderByndyu, описывающая уход от использования Repository в сторону применения связки QueryFactory + классы запросов Query. При этом в комментариях разгорелся весьма интересный диспут, касающийся целесообразности приведенного в статье решения. Было достаточно много интересных отзывов, среди которых особенно выделялись высказывания о том, что, дескать, QueryFactory не нужен и является лишней обузой, мешающей безболезненному добавлению, изменению и удалению классов запросов. В данной статье я хочу показать подход, который позволяет избавиться от применения QueryFactory, через активное использование IoC контейнера. Данную организацию работы со структурой классов запросов мы использовали в одном из наших недавних проектов, где в качестве IoC использовался Castle.Windsor.