disclaimer: данная статья является пошаговым руководством, которое поможет ознакомиться с основными возможностями Incoding Framework. Результатом следования данному руководству будет покрытое юнит-тестами приложение, реализующее работу с БД (CRUD + data filters). О Incoding framework ранее уже были статьи на habrahabr, но в них раскрываются отдельные части инструмента.

Часть 0. Введение

Для начала приведем краткое описание фреймворка. Incoding Framework состоит из трех пакетов: Incoding framework – back-end проекта, Incoding Meta Language – front-end проекта и Incoding tests helpers – юнит-тесты для back-end’а. Эти пакеты устанавливаются независимо друг от друга, что позволяет интегрировать фреймворк в проект частями: Вы можете подключить только клиентскую или только серверную часть (тесты очень сильно связаны с серверной частью, поэтому их можно позиционировать как дополнение).
В проектах, написанных на Incoding Framework, в качестве серверной архитектуры используется CQRS. В качестве основного инструмента построения клиентской части используется Incoding Meta Language. В целом Incoding Framework покрывает весь цикл разработки приложения.
Типичный solution, созданный с помощью Incoding Framework, имеет 3 проекта:

1. Domain (class library) — отвечает за бизнес-логику и работу с базой данных.
2. UI (ASP.NET MVC project) - клиентская часть, основанная на ASP.NET MVC.
3. UnitTests (class library)  — юнит-тесты для Domain.

Доброго всем времени суток, в этой статье хочу осветить ещё один компонент из библиотеки Incoding Framework.
Model View Dispatcher (MVD) — позволяет избавится от избыточного кода (а именно asp.net mvc controller) и упростить навигацию по проекту, уменьшив количество абстракций между клиентским и серверным кодом.

disclaimer: статья является ответом на критику (которая обрушилась на хабре), раскрывая потенциал IML на примере популярного приложения ToDo MVC.

Получил тумаков

Критика – это слово крайне мягкое по отношению к дискуссии, которая возникла к моей предыдущей статье, потому что это было больше похоже на избиение в котором были крайне не приятные комментарии (на фото топ бредовых), но также и объективные:

• Код на AngularJs не фонтан — сложно опровергнуть, хотя все они были с официального сайта и популярного руководства
• Слабые примеры – упор был на задачи, а не на сценарии, но соглашусь что более комплексное решение более полно раскрывает потенциал (я предложил некоторые наши проекты, которые открыты на open source, но они остались без внимания)
• Не знаешь AngularJs? – по понятным причинам это очень сильно задело разработчиков AngularJs
• Топик JS – это серьезная ошибка, потому что не используя asp.net mvc, сложно понять прелести типизированных TextBoxFor и других расширений.

Почему ToDo?

В комментариях предложили попробовать реализовать “Todo MVC” в качестве доказательства возможностей IML и сейчас мы посмотрим что из этого получилось. Во первых demo версия, которая имеет одно отличите от тех, что представлены для js framework, в том, что в качестве хранилища используется не local storage, а база данных, а также исходный код, который мы будем разбирать далее в посте. В процессе реализации я строил всю логику (расчеты подвала, скрытие элементов и т.д.) на клиенте, хотя на реальных задачах, проще (иногда необходимо) обновлять “точечно” элементы, которые имея IML код, знают, как себя вычислить и отобразить.

Code review

Стиль повествования в этот раз будет не сравнение одного решения с другим (иначе объем материала будет большим), а обзор кода, который получится при реализации приложения todo. Я упоминал выше о том, что в реализации IML присутствует и серверная часть, но в целях уравнивания решаемых задач для более объективного сравнения, сфокусируемся только на клиентской части.

disclaimer: сравнение не подразумевает поднятие “холивара”, а делает обзор задач, решаемых одним инструментом в сравнении с другим. Я не являюсь знатоком всех тонкостей angularJs, но прочитав 10 статьей обзора этого инструмента, привожу альтернативный пример решения тех же самых задач на IML.

Пред история

Моя предыдущая статья была знакомством с Incoding Framework, которое начиналось с IML (наша флагманская фича ). IML подтолкнул нас развить проект больше, чем набор утилит ( такого добра полно в любой команде разработчиков ) используемых в проектах компании, но это не значит, что другие компоненты не прорабатываются, а напротив «полируются» с не меньшей детализацией и это я попробую Вам доказать.

Серебренная пуля ?

Раньше я всегда был сторонником того, что у каждого решения есть свои минусы и плюсы, но CQRS на мой взгляд превосходит N-Layer, а также не имеет «противопоказаний» или «побочных эффектов», что делает его кандидатом на первый патрон в обойму, но обо всем по порядку.

Кто-то не слышал про CQRS?

Для тех, кто уже использует CQRS, первые разделы могут быть не интересны, поэтому прежде чем поставить ярлык «велосипед», предлагаю ознакомиться с разделом killing feature, который может Вас убедить в обратном. Тем же, кто использует N-Layer архитектуру, стоит задуматься о переходе на CQRS и чтобы подкрепить свое предложение я опишу наш путь к CQRS

Пара слов о себе — я работаю в компании Incoding Software, которая много лет успешно занимается аутсорсингом, выполняя Internet и Intranet проекты в различных областях ( медицина, доски объявлений, социальные сети и многое другое)

Incoding Framework — это клиент / серверное решение для разработки веб проектов на платформе asp.net mvc.

Состоит из трех частей:

• Серверная — реализация CQRS и Event Broker
• Unit Test Contrib — набор утилит и сценариев для быстрого написания тестов
• Клиентская — делится на:
  
  • IML — Декларативный язык ( Incoding Meta Language ), позволяющий описывать клиентские сценарии на C#
  • Model View Dispatcher ( MVD ) — CQRS на MVC, позволяет исполнять Command и Query без написания промежуточных Controller
  
  

примечание: особенность Incoding Framework в том, что каждая часть интегрируется между собой ( IML использует MVD для AJAX, MVD исполняет CQRS и т.д ), но позволяет применять по отдельности ( на Nuget 3 независимых пакета )

Так как рассмотреть каждую часть framework в одной статье не получится, то будет сделан акцент на самом интересном компоненте нашей библиотеки — это IML. Почему я выделил именно клиентскую часть, дело в том, что CQRS, Event Broker и Unit Test имеют множество аналогов в “мире” .net и быстро заинтересовать ( хотя мы имеем ряд особенностей ) крайне трудно, но IML это инструмент, который пока не имеет прямых аналогов.