Такое случается, что при разработке приложения прокрадываются баги, а некоторые из них так же являются утечками памяти (Memory Leaks). Особенно такое явление бывает распространено, когда ваше приложение работает с документами или с сессиями, которые можно открывать и закрывать. Вам нужно убедиться, что при закрытии все, что было создано именно для этого документа, будет удалено из памяти, а так же все ресурсы будут освобождены. Особенно неприятно, когда вы нашли такой баг с утечкой памяти, исправили его, а после очередного обновления кода – он опять проявился.

Однажды, после одного из исправлений утечки памяти – у меня всплыла мысль, неужели нет каких-нибудь инструментов, которые просто могут валидировать, что после закрытия все мои объекты удалены, что после очередного моего изменения кода я не вызову новых утечек памяти? В native мире, на самом деле, таких инструментов предостаточно (но, к сожалению, я не могу вам их назвать, так как не являюсь экспертом в этой области), в managed тоже полно, но они требуют запускать инструменты параллельно. Такие инструменты обычно имеют слова Memory Profiler в названии, а запускать их нужно параллельно с вашим приложением, чтобы проверять на утечки памяти, да еще их результат нужно постоянно анализивароть. Мне же захотелось использовать что-то в коде, какой-то инструмент, который я бы мог отключать, и который будет присутствовать на всем этапе разработки, обладающий возможностью мгновенно отреагировать на утечку памяти в моем коде. Решение, на самом деле, оказалось совсем простым. Я попробовал, основываясь на Weak Reference (слабые связи) классах создавать коллекцию объектов, за которыми мне нужно следить, и которые должны быть удалены из памяти в определенный момент. Основываясь на этом принципе, я создал очень простой Object Release Verification Framework с несколькими классами и интерфейсами. Данный инструмент я опубликовал на nuget.org, как portable library.

Итак, давайте рассмотрим на примере.

На прошлой неделе я, просто ради интереса, подготовил 4 примера в Еще одно сравнение паттернов MVVM и MVP для Silverlight. Примеры возникли не случайно, просто, попался на эту проблему пару недель назад. Там же был опросник о том, какие из примеров рабочие. Определить просил просто, посмотрев на код. Было получено 56 (вместе с моим) ответов, и только два из них были верными (вместе с моим). В этих примерах я уточнил, что опрос касается Silverlight, так как в WPF все немного по-другому.

Я уже когда-то поднимал тему сравнения паттернов MVP и MVVM при разработке Silverlight приложений: Выступление на ADD2010: Silverlight/WPF: возврат от паттерна MVVM к MVP. Вопрос, на самом деле сложный, какой из паттернов лучше. Я бы хотел продемонстрировать небольшой пример и подискутировать на эту тему в комментариях. Был бы рад, если кто-нибудь нашел бы хороший ответ на мой вопрос, который будет дальше.

Неделю назад напоролся на баг в Silverlight, точнее в DataGrid контроле, а он пришел, вроде, с Toolkit. Потребовалось больше часа, чтобы понять в чем проблема.

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

Как-то я поднимал уже тему про то, стоит ли покупать компоненты или может имеет смысл писать их самому. Хочется пожаловаться, просто накипело. Syncfusion меня очень сильно удивил. Есть у них библиотеки, включающие имя Web, ну, наверняка же, должно подразумеваться, что все классы, контролы должны уметь жить в многопоточной среде. А оказывается нет. В общем, хочу провести антирекламу Syncfusion. Я могу точно сказать – эти библиотеки покупать не стоит. Берут они, наверное, свое, только обилием количества решений, контролов, сред. Но, не стоит это тех денег, а особенно сил, которые нужно будет тратить на решения проблем.