Хотел бы сказать пару слов о книге Professional Test Driven Development with C#. Выбрать книгу по популярным технологиям и техникам программирования не так сложно. На каждом форуме написано, что если хочешь познать .NET – не обойтись без Рихтера. Сложнее с менее популярными темами. Итак, TDD…

При разработке веб приложений, мы используем Asp.net MVC и backbone.js. При написании логики проверки достоверности у нас возникла проблема дублирования кода. Логику приходится описывать в модели на сервере и в модели backbone на клиенте. Хотелось бы автоматически перенести правила валиции с сервера на клиент. Для решения этой проблемы мы реализовали аналог стандартной ненавязчивой проверки достоверности данных MVC для backbone.js Подробности ниже.

Привет Хабровчанам! На Хабре уже обсуждался вопрос интеграции .Net c Matlab'ом. Цель же этой статьи — показать, как можно быстро и удобно решить обратную задачу: вызывать управляемый код из произвольных .Net библиотек в Matlab.

Зачем это нужно?

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

Оглавление

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

Рекомендации по разработке пользовательского интерфейса

Целью этого раздела является предоставление поверхностного руководства для XAML дизайнеров и программистов, создающих приложения с использованием WPF, Silverlight, или Windows RT и библиотеки Prism. В этом разделе описывается компоновка пользовательского интерфейса, визуальное представление, привязка данных, ресурсы и модель отображения данных. После прочтения этого раздела, вы получите поверхностное понимание того, как создавать пользовательский интерфейс с использованием библиотеки Prism, а так же, как применять техники, которые могут помочь вам создать поддерживаемый UI в модульном приложении.

В данном посте будет рассмотрен процесс создания меню навигации и хлебных крошек в проекте asp.net MVC3. Сначала мы создадим пустой проект, потом добавим sitemap провайдер, несколько контроллеров и представлений и в итоге заставим провайдер вывести хлебные крошки.

Практическое использование MvcSiteMapProvider в ASP.net MVC

В данной статье показано использование MvcSiteMapProvider для построения динамического меню, как с его помощью сделать карту сайта и «breadcrumbs».

Практику использвания MvcSiteMapProvider я буду показывать на учебном проекте MVC Music Store.

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

Не так давно мне принесли небольшую программку (менее 1000 строк, более четверти — комментарии и пустые строки) с задачей «сделать что-нибудь красивое, например, графики и интерфейс». Хоть программа и небольшая, а переделывать её не хотелось — дядька её ещё два месяца будет старательно обкатывать и вносить коррективы.

Результаты работы в виде нескольких кусков кода и вагона текста старательно изложены под катом.

В ASP.NET MVC метаданные — атрибуты, описывающие поля модели, используются как при генерации разметки (вывод названия поля, его заполнителя и т.д.), так и при валидации данных (вывод правил валидации). Условно можно выделить 2 вида валидации:

• клиентская валидация
• серверная валидация

Клиентская валидация хороша тем, что пользователь сразу же видит допущенные ошибки в заполнении полей и может внести поправки без необходимости отправлять данные серверу (ненавязчивая валидация). Именно этот тип валидации необходим в нашем случае.


Итак, необходимо реализовать автоматический вывод метаданных модели MVC на клиентскую сторону и ненавязчивую валидацию.

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

Собственный класс. Выбрасывайте исключения на основе собственного класса, унаследованного от Exception, а не напрямую — на основе Exception, потому что это дает возможность определить свой собственный обработчик и отделить отслеживание и обработку исключений, выбрасываемых вашим кодом и кодом фреймворка .NET.

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

Вот несколько необычных фактов о языке C#, о которых знают лишь немногие разработчики.

1. Индексаторы могут использовать params параметры

Мы все знаем, как обычно выглядят индексаторы x = something["a"], а так же код необходимый для его реализации:

public string this[string key]
 {
   get { return internalDictionary[key]; }
 }

Но знали ли вы, что для доступа к элементам вы можете использовать params параметры x = something["a", "b", "c", "d"]?
Просто напишите ваш индексатор следующим образом:

Посвящается тем 45% .NET разработчиков, что до сих пор сидят на фремворках 2.0-3.5.

Да, вы не ослышались. async и await во втором дотнете. Но обо всём по порядку.

Зачем?

В какой-то момент мне надоело вручную возиться с написанием асинхронного кода. Async/awat выглядели слишком вкусными, чтобы не попробовать. Зная, что Microsoft при добавлении новых возможностей в язык и компилятор не привязывает их жёстко к фреймворку (так, extension-методы и LINQ отлично можно использовать во втором .NET, если где-нибудь объявить System.Runtime.CompilerServices.ExtensionAttribute), и видя Async CTP, добавляющего возможность использования async/await в 2010-ую студию при использовании в качестве целевого фреймворка .NET 4.0, я подумал, а почему бы и нет?

Наверное, уже не существует веб разработчика, который не слышал о Ajax. Microsoft в такой ситуации не может оставаться в стороне, с каждым релизом старается облегчить жизнь именно нам, ASP.NET MVC разработчикам. Но прежде чем я продолжу статью, немного отступлюсь от темы.

Когда я познакомился с MVC фреймворком, он был тогда только во второй версии и, столкнувшись с такими хелперами как @Ajax...., честно говоря, их реализация на стороне клиента меня не впечатлила. Нет, так нет, подумал я про себя, у меня есть jQuery со своим $.ajax, мне его за глаза. Вот и забыл я про них на несколько лет, к своему великому сожалению проморгав этот момент с третьим релизом. Что было, то было. Благо что взялся за ум и почитал две книги по MVC 4. Далее расскажу, как можно сократить написание строк кода благодаря хелперам, упомянутым мною выше.

Начну с того, что MVC может работать с двумя вариантами Ajax библиотек (конечно я же имею ввиду с коробки, не более того) — jQuery и Microsoft Ajax. Чтобы знать, для какого адаптера создавать разметку, существует настройка в web.config UnobtrusiveJavaScriptEnabled и соответствующее значение true (для работы с jQuery) и false (для работы с Microsoft Ajax). Если же нам необходимо поменять значение только для одного представления, можно воспользоваться методом — @{Html.EnableUnobtrusiveJavaScript(bool);}. Хочу обратить внимание, что данная настройка влияет и на формирование валидационных данных на стороне клиента.

Это 2 часть серии «Понимание ненавязчивой валидации в ASP.Net MVC»

1. Работа плагина jQuery validate изнутри
2. Понимание Html-кода, сгенерированного ненавязчивой валидацией в ASP.Net MVC
3. Внутренняя работа плагина unobtrusive jQuery validate в ASP.Net MVC.

О чем мы поговорим в этой статье:

• Идея ненавязчивого JavaScript
• Разница между нормальной и ненавязчивой валидацией
• Понимание ненавязчивой валидации:
  
  • Элементы «input», правила их валидации и как они работают
  • Сообщения валидации и как они работают в ненавязчивой валидации.
  
  

Основная идея ненавязчивого JavaScript

Microsoft представил первый модуль валидации в первой верисии MVC. Модуль совершенствовался с каждой версией, и превратился в ненавязчивую валидацию в ASP.Net MVC 3.
Если коротко, даже в современном JavaScript, который мы пишем в основном в отдельном js файле, мы нуждаемся иногда в данных, связанных с Html, и поэтому записываем метаданные объектов JavaScript внутри страницы Html. Мы вызываем функцию из файла js, которой передаем метаданные объекта на странице.

Одна из целей ненавязчивого JavaScript отделить JavaScript от Html разметки.
Почитать больше об этом можно тут ( автор отсылает нас к статье о ненавязчивом JavaScript в англоязычной Википедии, прим. переводчика)

Разница между нормальной и ненавязчивой валидацией.

Ниже представлен код модели и Html разметки, сгенерированной используя валидацию MVC 2 и ненавязчивую валидацию MVC 3.

Оглавление

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

Во время взаимодействия с пользователем, UI приложения может подвергаться значительным изменениям, в зависимости от того, какие действия должен выполнять пользователь, и с какими данными он работает. Процесс, когда приложение координирует изменения пользовательского интерфейса, часто называют «навигацией (navigation)».

Зачастую, «навигация» означает, что одни элементы управления удаляются, а другие добавляются в пользовательский интерфейс. В других случает, это означает обновление вида уже существующих элементов управления. К примеру, некоторые элементы управления могут скрываться, или сворачиваться, а другие, наоборот, появляться, или разворачиваться. Аналогично, «навигация» может значить, что данные, показываемые в некоторых элементах управления, могут обновляться для отображения текущего состояния приложения. К примеру, при сценарии "master-detail", данные, отображаемые в detail-представлении, обновляются в зависимости от того, какой элемент выбран в master-представлении. Все эти сценарии могут быть расценены, как «навигация», так как пользовательский интерфейс обновляется для отображения внутреннего состояния приложения и того, какую задачу выполняет пользователь в текущий момент.

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

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

Концепция

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

В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.

Оглавление

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 и рассказывают о том, как они были расширены для поддержки навигации на основе представлений.

Оглавление

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

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

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

• Использование команд (Solution commanding). Используйте для реагирования на действия пользователя.
• Контекст региона (Region context). Используйте для передачи контекстной информации от host-элемента управления к представлениями в регионе. Этот подход в некотором роде аналогичен DataContext, но не полагается на него.
• Общие службы (Shared services). Вы можете вызвать метод на сервисе, который, в свою очередь, сгенерирует событие, на которое могут быть подписаны получатели. Используйте этот подход в том случае, если все остальные подходы не применимы.
• Агрегация событий (Event aggregation). Для передачи сообщений между моделями представлений, презентерами, или контроллерами при отсутствии ожиданий о непосредственной реакции на сообщение.

В начале работы junior разработчиком мне пришлось столкнуться с таким малопонятным для меня на то время понятием, как Inter-Process Communication. Это была полная дикость для начинающего программиста, который и в рамках логики одного приложения ориентировался то с большим трудом. Стоит упомянуть, что проект написан на Delphi, а сам механизм IPC реализован с помощью File Mapping и Windows Messages.
Что удивительно, узнал я том, как вся эта система работает изнутри, спустя едва ли не год, когда пришлось маленько с ней повозиться. И только тогда я окончательно осознал, насколько высококлассной была её реализация, а API – удобен. Кому интересна реализация чего-то похожего на вышеупомянутую систему под С# – прошу под кат.

Вы все еще публикуете проект вручную? Тогда мы идем к вам

Под катом гайдлайн по внедрению CI для .NET проектов «с нуля», включающий:

1. Автоматические ежедневные сборки
2. Уведомления о проблемах
3. Интеграцию с баг-трекером и системой контроля версий
4. Версионирование продукта
5. Версионирование базы данных
6. Автоматизированные выкладки и бекапы