Думаю, что даже уже начинающий разработчик должен быть знаком с понятием Inversion of Control (сокращают как IoC). Любой проект сейчас начинается с выбора фреймворка, при помощи которого будет реализован принцип внедрения зависимостей. Если взять русскую википедию, то там определение для IoC выглядит следующим образом:

Инверсия управления (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах и входящий в пятерку важнейших принципов SOLID.

IoC решает очень простую, но и очень важную задачу, он уменьшает зависимость между компонентами системы. В случае использования, например, внешних библиотек вы делаете так, что ваше приложение зависит только от некоторого интерфейса (абстракции), сама же реализация скрыта, и в любой момент может быть заменена другой. Простой пример: нравится log4net, но не уверены, что он останется с вами навсегда; делаете свой интерфейс ILogger, во всех классах используете именно эту абстракцию, получая ее из IoC контейнера, реализуете класс, который использует log4net и регистрируете его для этой абстракции в IoC, и в случае перехода на другую библиотеку вам достаточно поменять реализацию ILogger и просто регистрировать в IoC именно теперь новую реализацию использующую что-то другое.

Для .NET платформы, как и для любых других платформ, есть огромное разнообразие библиотек, которые можно использовать в проектах: Unity, StructureMap, Ninject, Castle Windsor. Это только часть, которую я вспомнил на данный момент, но есть и еще немалое количество, помню даже кто-то из знакомых писал свой. Для бизнес проектов, ну и для проектов, бинарники которых вижу только я, мне хватает этих библиотек, да более того мне хватает только Unity. Но вот, если хочется написать какую-нибудь утилиту или приложение для общественности, либо библиотеку, то написав приложение в 100 килобайт тянут за ним еще по 300 килобайт библиотеки для записи логов и 300 библиотеки, реализующей для тебя IoC немного дико. И дико иметь привязку на какую-то специфичную реализацию IoC, особенно, если вы распространяете библиотеку, ведь ваши пользователи могут держать в привычке использовать совершенно другую реализации IoC. А в случае приложения дело даже не в размере, а в том, что у вас вместо всего одного exe файла будет поставляться еще гора каких-то непонятных библиотек (все зависит конечно еще от того, как будете распространять свое приложение). Есть, конечно, еще и простое решение, можно объединить все ваши бинарники приложения при помощи утилиты ILMerge.exe в один exe файл. Ну а все-таки, если дело в размере? Хочется, чтобы приложение было действительно очень небольшим в размерах.

Пару дней назад я упомянул, что подал тезис на конференцию разработчиков Application Developers Days 2010, которая пройдет в Ярославле 23-24 сентября. Сегодня меня обрадовали, объявили, что мой доклад прошел, его тема «Silverlight/WPF: возврат от паттерна MVVM к MVP»:

В данном докладе автор на примерах обрисует особенности реализации знаменитых паттернов MVP и MVVM, применяемых при разработке приложений на WPF и Silverlight. Даст их подробное сравнение на примере данных технологий, укажет основные плюсы и минусы реализаций данных паттернов, а так же обрисует доработанный паттерн MVP с облегченной моделью представления, который является синтезом паттернов MVP и MVVM для разработки приложений на данных технологиях.

Я уже довольно давно недоволен паттерном MVVM, а вот почему, и что я предлагаю взамен (это предложение строится на моем опыте, а так же опыте коллег-разработчиков WPF/Silverlight) я расскажу на конференции Application Developers Days 2010 в Ярославле. Доклад на 100% еще не готов, потому если есть какие-либо предложения, идеи или советы – буду рад комментариям. У меня осталась одна подписка Visual Studio 2010 Ultimate + MSDN Premium Subscription, которую, скорее всего я разыграю за интересный вопрос или предложение на конференции (если они действительно будут). Если нет, то отдам докладчику, который мне понравится своим докладом и которому она действительно нужна.

Полностью тезис можно прочитать в этом документе add.doc, основная идея доклада из тезиса ниже.

В данной статья я бы хотел рассказать, в чем различие данных паттернов. Начнем с первого главного – Model-View-Controller – это фундаментальный паттерн, который нашел применение во многих технологиях, дал развитие новым технологиям и каждый день облегчает жизнь программистам. Если вы начнете спрашивать архитекторов о том, как реализовать данный паттерн, то, я думаю, вы сможете услышать несколько разных ответов и соответственно несколько разных решений. Вообще, объединяет все эти паттерны – выделение User Interface (UI) от логики программирования, что позволяет дизайнерам делать свою работу, не задумываясь о коде программы. Если вспомнить школьное и студенческое программирование, то всплывает картина огромного количества строчек, написанных в code behind интерфейсов, что не является хорошей практикой. Так же есть предоставляется возможность выделения модели данных, что дает разработчикам возможность создания модульных тестов над ними.