Глобальная view model для представлений asp.net mvc

Прежде чем рассказывать о реализации глобальной view model в представлениях, поясню, зачем это нужно. При использовании технологии asp.net mvc для создания web-приложений существует возможность представлению (содержащему привычную для нас html – разметку) передать класс - модели, который генерируется в контроллере, и тогда это представление будет называться строготипизированным. Однако бывают случаи, когда в представление необходимо передать несколько моделей, что опять же, является тривиальной задачей (см. ViewData или PartialView). Но иногда бывают случаи, когда необходимо сделать одну общую модель для нескольких представлений, при этом они не должны перестать быть строготипизированными. Приведу пример из реального проекта, где это понадобилось. Итак, необходимо организовать проведение баллистических расчетов для различных космических аппаратов, которые находятся на обслуживании и выполняют различные задачи (рис.1).

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

Restful API

Точное определение restful web service можно найти по первой ссылке в Google, тут я расскажу про задачи, которые могут быть решены с использованием таких сервисов, а также покажу реализацию 4-х методов, которые должны быть в restful  сервисах (Get, Post, Put, Delete).

Итак, задача: у нас есть web приложение, которое отвечает за управление группировкой космических аппаратов, но кроме этого приложения существуют еще сторонние программы, которым необходим доступ к начальным условиям. Для решения этой задачи был сделан api controller, который реализовывал все необходимые операции. Контроллер возвращает либо JSON либо XML, в зависимости от заголовка запроса, но на реализации это никак не сказывается.

Unit testing and Dependency Injection (DI) pattern.

Как известно использование сильно связанных классов это плохо, так как попытка внести изменения в один класс, неизбежно повлекут за собой, целую цепочку изменений в других классах. Особенно это проявляется при поддержке больших систем, состоящих из огромного числа классов. Кроме того, такой подход увеличивает сложность тестирования, так как один класс невозможно протестировать отдельно от другого. Для уменьшения связанности классов необходимо программировать на уровне интерфейсов, а не на уровне реализаций, т.е. всю логику, которая гипотетически может измениться необходимо, по возможности,  выносить в интерфейс. Затем, при создании  класса, в его конструктор можно передать объект, реализующий необходимый интерфейс и им инициализировать объект внутри класса (пример). Использование такого подхода описывает паттерн Dependency Injection.  Многие проблемы, возникающие при развитии  системы, могут быть решены,  если при программировании логики работы стараться придерживаться принципов проектирования классов (S.O.L.I.D).  При переходе к программированию на уровне интерфейсов  создание объектов может сильно усложниться, так как каждый раз при создании нового объекта нам необходимо будет настраивать  его зависимости.  Для простых объектов это может показаться не очень сложным, однако при усложнении системы простая инициализация объекта будет вести за собой целую цепочку вызовов разрешений зависимостей, и это будет необходимо делать при каждой инициализации объекта.  Для решения этой проблемы существует множество DI frameworks, которые при правильной настройке позволяют легко инициализировать объекты вместе с их зависимостями. В своей работе я использовал два framework-а: Unity и Ninject. Скажу честно, какой-то принципиальной разницы между ними не нашел, кроме того, что Ninject интегрируется с MVC «из коробки» и еще мелких различий, поэтому тут опишу только Ninject.

Использование паттернов Unit of work и Generic Repository c Entity Framework 5.0

Использование паттернов Unit of work и Generic Repository c Entity Framework 5.0
Паттерн Unit of Work, по сути, нужен для консолидации всех методов, которые работают с базой данных. С его помощью можно улучшить контроль над изменением данных в БД, а также оптимизировать использование БД при обработке нескольких запросов одновременно. Использование Generic Repository упростит работу с EF Entities.
Создаем интерфейс IRepository, который описывает все необходимые операции с БД:

public interface IRepository<TEntity>  where TEntity : class
    {
        IEnumerable<TEntity> Get();
        TEntity GetById(object id);
        void Insert(TEntity entity);
        void Delete(object id);
        void Delete(TEntity entityToDelete);
        void Update(TEntity entityToUpdate);
    }