Проектируем стандартное приложение (Ninject+WinForm)

Эта статья предназначена для тех, кто только начинает осваивать механизм Dependency Injection (DI). В ней я хочу рассказать, как спроектировать простое приложение с использованием DI так, что бы в дальнейшем это приложение можно было бы легко развивать, модифицировать и, в конечном счете, получить сложную развернутую систему.

Используемый инструментарий

Для примера, я буду использовать Ninject в качестве DI и Windows Form, в качестве UI. Понятное дело, что это совершенно не принципиально, так как тонкости различных DI систем я тут не рассматриваю, а принципиально они все решают одни и те же задачи.

Постановка задачи

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

Простейшая структура

Для примера, создадим структуру, состоящую всего из трех классов.

// Тип транспорта
public class TransportType
{
   public int Id { get; set; }
   public string Caption { get; set; }
}
// Модель транспорта
public class TransportModel
{
   public int Id { get; set; }
   public string Caption { get; set; }
   public string Description { get; set; }
}
// Конкретная единица - транспортное средство
public class Transport
{
   public int Id { get; set; }
   public string Caption { get; set; }
   public TransportType Type { get; set; }
   public TransportModel Model { get; set; }
}

Естественно, я предполагаю, что каждый класс будет отмапирован на табличку в некотором репозитории/базе данных с использованием какого-нибудь ORM fraimwork-а. Однако, для данной статьи это не принципиально.

Data Binding на Linq

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

Предисловие

Давным-давно, когда я только начинал постигать хитрости языка C# (а, так же, технологии .Net в целом), основной рабочей технологией была Windows Forms, WPF еще не было даже в проекте, а технология web была развита крайне слабо и, как следствие, применима в весьма узком круге задач. Нарисовав свою первую формочку, я, разумеется, задумался, как отобразить в нее свои данные. В случае, если форма readonly, задача решается просто - нужно сделать простые присвоения и все. Но, что если данные должны редактироваться и присваиваться назад, в область данных по триггерам Changed. Прямой подход (присвоить свойство, подписаться на его изменения, считать свойство в триггере) я откинул сразу, как слишком громоздкий, очень плохо читаемый и крайне не удобный для изменений.

Первые шаги. Что предлагают авторы?

Разумеется, первое, что я сделал - это стал изучать мануал и штудировать форумы. Из мануала от компании Микрософт я понял, что технология WinForms предоставляет очень мощный, удобный и универсальный механизм биндинга данных. Копая глубже и подкрепляя знания форумами и личными экспериментами, я понял, что почти все "странности" этой системы реально можно обойти. Еще более глубокое изучение показало, что все особенности и странности, кажущиеся на первый взгляд явными багами, на самом деле являются фичами. А все сложности и неудобства механизма оправданы теми или иными "высшими целями". Проникнувшись этими самыми "высшими целями", я, не долго думая, набросал себе простенький движок биндингов на чистом рефлекшине, реализовав минимально-необходимый для меня функционал и забыл про эту проблему на несколько лет.