.NET *

Сейчас пришла пора разобраться с тем, что происходит с кодом от момента написания ASPX/ASCX- разметки и CS-кода до момента их физического выполнения в виде некоторого скомпилированного кода на сервере.

Specter – инфраструктура для составления объектно-поведенческих спецификаций для .NET. Он предоставляет возможности для обеспечения разработки, руководствуясь поведением системы (BDD), требуя от разработчиков написания исполняемой спецификации для объектов перед написанием самих объектов. Технически это ни чем не отличается от разработки по средствам тестирования (TDD), хотя различия в форме написания снимают психологический барьер для написания “тестов” для кода, которого ещё не существует. Есть множество проектов для различных платформ, реализующих данную идею (К примеру RSpec для Ruby, NSpec для .NET. Подробнее о средах здесь).
Specter использует возможности мета-программирования языка Boo (CLR .NET) для написания неплохо читаемых спецификаций.

На днях представился случай познакомиться с ASP .NET MVC 1.0, о которой уже не раз читал в блогах и здесь, на Хабре. С первого взгляда понравилась простота используемой концепции и логичность связи с архитектурой ASP .NET (привычные aspx, ascx, masterpages, Global.asax — только теперь используемые несколько иначе). Однако, при всех удобствах, способа задания роутинга и передачи параметров в виде {Controller}/key1/value1/key2/value2 я не нашел. Их можно задать сколько угодно, но, к сожалению, при этом они должны стоять строго на указанном месте, а это иногда очень неудобно, особенно при передаче большого количества значений. Ведь какие-то аргументы могут иметь значения по умолчанию, и запихивать их в URL принудительно — не лучшее решение. Конечно, можно было бы воспользоваться стандартным, ?key1=value1&key2=value2 способом, но лично мне почему-то захотелось иметь возможность задавать параметры именно в таком, «MVC-style», если можно так выразиться :)

Сегодня столкнулся с довольно странной вещью. При работе с Windows.Forms.ScrollBar пользователь не может достигнуть максимального значения. Ни мышью, ни клавиатурой нельзя установить бегунок на «максимум».
Например, пусть на форме есть hScrollBar (наследник ScrollBar).
Его свойства:

hScrollBar1.Minimum = 0,
hScrollBar1.Maximum = 100.

При таком раскладе пользователь не может получить значение hScrollBar1.Value больше 91, хотя максимум 100.

Думаю все, кто использует Asp.net для разработки web-сайтов, прекрасно знают, что в Asp.net имеет встроенное кеширование UserControl`ов.
Любой пользовательский элемент может быть закеширован на определённое время в зависимости от различных условий. такой кэш работает крайне быстро и в большинстве случаев этого вполне достаточно, однако в проектах, в которых я принимаю участие, этого оказалось мало.
Основные недостатки заключались в следующем:

• Кэш может зависеть не только от параметров строки запроса, но и от каких-то других параметров, например от файлов-cookie или типа пользователя (например, в интернет-магазине это может быть физическое или юридическое лицо)
• Весь кэш не должен пропадать при перекомпиляции проекта (это обычно происходит при изменении файла конфигурации web.config)
• При необходимости нужно иметь возможность очистить весь кэш

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

После выхода Visual Studio 2010 beta 1 — первым делом нужно разобраться, что же дает нового нам C# 4.0 (так как это мой основной язык программирования — для меня это является важным). Первым делом должен вам порекомендовать примеры C# 4.0, которые можно скачать отсюда (там же есть документ New Features in C# 4.0, которая послужила основой для этого топика). Документацию по .Net Framework 4.0 beta 1 можно посмотреть в MSDN. Дальше будут следовать мой небольшой опыт знакомства с новой версией .NET.
 

Этот топик меня побудило написать статья о работе с System.Drawing.Bitmap http://habrahabr.ru/blogs/net/60085/. Мне часто приходилось сталкиваться в коде с попиксельной обработкой изображений для типовых операций, в то время как в .NET есть классы ColorMatrix, ColorMap, ImageAttributes для некоторых видов преобразований изображений.

Класс System.Drawing.Bitmap очень полезен в инфраструктуре .NET, т.к. позволяет считывать и сохранять файлы различных графических форматов. Единственная проблема – это то, что он не очень полезен для попиксельной обработки – например если нужно перевести битмап в ч/б. Под катом – небольшой этюд на эту тему.

Ни для кого не секрет, что вчера стало возможным скачать для подписчиков MSDN Visual Studio 2010, многие знают, что среда будет переработана на WPF, в сети уже есть несколько скриншотов от добрых людей новой среды разработки. Но для меня, как, думаю, и для многих, главным фактором перехода (я не про переход на бету, а вообще) на новую студию откладывает еще обычно и выход любимого аддона Resharper. Так было по крайней мере с 2008 версией: jetbrains выпустила Resharper версии 4.0 (который стал поддерживать VS 2008) только через несколько месяцев после выхода самой студии.
С Visual Studio 2010 ситуация кардинально изменяется, разработчики Resharper уверяют нас (там же смотрим несколько скриншотов), что в июне уже можно будет пощупать Resharper версии 5.0 (им нельзя верить на 100%, так как выход Resharper 4.0 они откладывали ;) ). Ну в любом случае приятно, что до выхода Release версии студии любимый аддон уже будет в боевой готовности и большое спасибо команде JetBrains!
P.S. Говорят, что устанавливать его будет очень просто, через Extension Manager в Visual Studio 2010 (что то типа галереи аддонов).

Перед моей поездкой в Индию я купил нетбук HP Mini 2140. Это прекрасная вещь. Он весит всего 1,8 кг. Поддерживает максимальное разрешение 1024 x 576 (нормальный по ширине но укороченный по высоте). Он обладает клавиатурой почти нормального размера. Моей любимой особенностью является то, что он может работать порядка 8 часов – что довольно таки долго.

После релиза preview ASP.NET MVC MonoDevelop addin, я решил попробовать его на Маке.

Хотя MonoDevelop 2.0 на Маке до сих пор в alpha-врсии, он получше того, что было в версии 1.0. Помимо проблем с перерисовкой GTK+, основными проблемами в Мак-интеграции являются реализация Ctrl-Click, меню верхнего уровня и Мак шоркатов. Сделать в MonoDevelop полноценную поддержку Мака –это наша цель в MonoDevelop 2.2.

Важно: этот подход устарел, теперь можно просто использовать DirectWrite и получать все плюшки OpenType. Пример конкретной реализации можно найти вот тут.

Введение

Как известно, в WPF есть достаточно мощная встроенная система типографики. К сожалению, эта система ориентирована в основном на работу с документами и, тем самым, все типографические изыски вроде поддержки OpenType невозможно использовать для какого-нибудь простого контрола вроде Label. Но, не смотря ни на что, есть все-таки возможность получить качественную отрисовку текста – просто нужно немного помучаться.

Хочу рассказать немного о Linq-To-Sql тем, кто его еще не использовал, но есть идеи использовать в будущих проектах (а так же может услышать некоторые комментарии о том, как еще можно с ним работать). Так сказать — пару слов о том, как необходимо разработать архитектуру приложения, чтобы безболезненно использовать DLinq.
У меня был до знакомства с Linq-To-Sql небольшой опыт с ORM системой NHibernate, поэтому как должна выглядеть полноценная ORM я представляю. Сразу скажу, что Linq-To-Sql не является полноценной ORM, а скорее просто представление в объектах записей таблиц. Сделать объекты как захочется не получиться (не похожие по своей сущности на маппинные объекты базы данных), а исходить надо будет как раз от реляционной структуры (с некоторыми оговорками).
Итак, думаю всем известно как можно работать с DLinq. Если у нас есть созданная модель ModelDataContext с объектами Entities, то вот пример загрузки объекта

using (ModelDataContext dataContext = new ModelDataContext())
{
  Entity obj = (from e in dataContext.Entities
        where e.EntityID = 10
        select e).FirstOrDefault();
}

* This source code was highlighted with Source Code Highlighter.

Дальше мы работаем с объектом obj, и в какой то момент нам нужно сохранить измененные данные. Как это сделать? В полноценных ORM системах есть возможность использовать методы Detach и Attach, смысл их простой, отцепляем объект от первого DataContext и покручиваем к другому. В DLinq метод Attach есть, а вот Detach-а нету, из-за чего нам приходиться подгружать объект заново в ModelDataContext и выставлять изменения ему (так сказать по каждому свойству). Может быть и другой вариант: клонировать объект, тогда он не будет зависеть от предыдущего ModelDataContext, НО, тогда, если есть у этого объекта ссылки на другие объекты, то с ними тоже нужно будет что то делать.
Можно делать и по другому. Работать с длинными сессиями — ModelDataContext открывать на задачу, например: загрузка, отображение объекта, и его сохранение, и только потом вызывать Dispose у ModelDataContext. Данный метод освобождает нас от повторных подгрузок объекта. Но возникнут другие сложности — если жизнь ModelDataContext будет разрастаться, скажем вы будете теперь держать открытым ModelDataContext на загрузку списка объектов, выбор одного из объектов, редактирование одного из объектов, добавление, удаление, то в случае, когда у вас будет вываливаться ошибки в базе данных (к примеру, невозможно удалить, потому как на него ссылаются), то нужно будет: удалять те объекты (вызывать DeleteOnSubmit(entity)), которые пытались добавить(InsertOnSubmit(entity)) у ModelDataContext, так же добавлять те объекты, которые пытались обновлять, ну и Refresh-ить объекты, которые хотели просто обновить. В общем странно, почему не сделали в DLinq стандартный Rollback метод, вроде все должно быть прозрачно.
Выбор пути, по которому вы будете использовать DLinq в вашем проекте, зависит только от вас и от вашего проекта. Если есть еще какие либо методы работы с Linq-To-Sql с удовольствием послушаю и приму к сведению.

Методика все та же — минимум объяснений, максимум рецептов. Для глубинного понимания происходящих процессов рекомендую обратиться к документации в MSDN — этот раздел уже даже перевели на русский язык.

Давайте поговорим о строках, точнее об их переворачивании средствами .Net/C#. Так уж сложилось, что в стандартной библиотеке соответсвующей функции не наблюдается. И как мне подсказывают, написание функции обращения строки довольно популярный вопрос на собеседованиях при приеме на работу. Давайте посмотрим, как можно эффективно перевернуть строку средствами данной платформы.

Под катом приведен сравнительный анализ быстродействия разных методов переворачивания строки.

Как вы, наверное, помните из моей предыдущей статьи, взаимодействие unmanaged и managed кода представляет определенную проблему, даже для опытных разработчиков. Причина этого — необходимость понимать, какие процессы происходят при пересечении данными границы CLR.

К сожалению, нередко проблема наладить взаимодействие встает у тех разработчиков, которые слабо знакомы с подноготной технологии COM и возможностями .NET для обеспечения взаимодействия. Это нормально — нельзя знать все на свете. Потому я не буду здесь объяснять всю суть проблемы маршаллинга данных из unmanaged в managed и обратно, а просто дам несколько рабочих рецептов, которые помогут вам тогда, когда нужно срочно и завтра, и вы с тоской смотрите на английское издание книги Inside OLE и понимаете, что разобраться в этом за день нет никакой возможности.

Однако, для тех, кто неплохо в этом разбирается, в конце статьи есть небольшой бонус — способ организации out-process COM на .NET. Честно говоря, я добросовестно считал, что сделать out-process COM с помощью .NET невозможно, однако буквально вчера выяснилось, что все-таки нет, можно. В связи с этим, рассказывать про архитектуру .NET Pipe RPC я скорее всего не буду — она достаточно сложна, однако все предоставляемые ей возможности с легкостью заменяет out-process COM.

Итак, перед нами Linq-to-Sql. Перед нами стоит задача узнать какие поля могут иметь значения null, а какие нет — решение данной задачи может, например, помогать в подсветки обязательных полей на форме, либо просто для валидации данных, перед их установкой в свойства объекта.

Сегодня 23 апреля 2009 года на факультете матмеха Уральского Государственного Университета (УрГУ) прошла встреча участников Уральской группы пользователей .NET. На встрече были зачитаны два интересных доклада на темы: «Unity Application Block — Unity Container» и «Composite Application Library». Было очень интересно, подробности под катом.

Managed код и .NET Framework – совершенно замечательная вещь с точки зрения программиста, которому надо кровь из носу выдавать максимально стабильно работающие программы. Использование .NET позволяет очень сильно сократить затраты на разработку, тестирование и сопровождение программных продуктов, особенно по сравнению с C++ или Delphi.

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

Однако нет такой проблемы, которую нельзя решить (пусть даже с помощью топора и лома). Сегодня у нас краткий обзор возможностей организации взаимодействия между managed и unmanaged кодом. Многие C# и особенно VB.NET программисты боятся этого, но на самом деле в этом нет ничего страшного. Начнем мы с самых примитивных методов, которые будут интересны разве что новичкам (поэтому матерые волки .NET могут с чистой совестью первую часть статьи пропустить), и закончим описанием того, что делать, если хочется написать программу на .NET, но сделать это невозможно (а такое тоже бывает). Естественно, к каждому случаю будут приведены конкретные примеры, быть может, хабрачеловеки расскажут мне о моей собственной велосипедности. Параллельно я скажу пару слов о подводных камнях при работе с VSTO и Windows Shell.

5я встреча Петербургской группы ALT.NET пройдет в четверг, 7го Мая в 19:00.
Встречи группы проходят по адресу Биржевая Линия дом 14, офис 409 (4й этаж).
Программа 19:00 – 21:00 — Паттерны Repository и Specification.
Применение Linq2xxx (на примере Linq to NHibernate), Артем Смирнов