Ведущий разработчик
0,0
рейтинг
20 января 2014 в 18:46

Разработка → Incoding rapid development framework из песочницы

C#*, ASP*, .NET*
image

Пара слов о себе — я работаю в компании 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 это инструмент, который пока не имеет прямых аналогов.

Не имеет аналогов, то как решаются задачи ?


У IML нету прямых аналогов, но конечно есть косвенные:
  • JavaScript
  • Jquery
  • AngularJS, Backbone, Marionette
  • TypeScript


Без JavaScript, не построить веб сайт

Вам приходится бороться со всеми сложностями:
  • Ошибки только в runtime
  • Динамическая составляющая языка, которая становится проблемой в больших приложениях
  • Оказывается null бывает разный ( null, undefined, 'undefined' )
  • И многие другие “прелести” нетипизированных языков


Не слышал, у меня же Jquery

С появлением Jquery разработка веб приложений стала проще, но с ростом сложности приложений на клиентской стороне скриптовый подход к написанию кода стал не оправдан из-за возрастающего уровня дубляжа, а такие «особенности» JavaScript, как глобальные функции и переменные ещё больше усложняют поддержку крупных проектов.

Хорошо, построим архитектуру на UI

Архитектура MVVM или MVС, построенная на JS, обеспечивает коммуникацию с сервером, но когда на стороне клиента появляется своя модель, то приходится её синхронизировать с той, что на серверной стороне и это разделяет разработчиков на front end и back end.
примечание: идея разделения программистов на серверных и клиентских, кажется крайне неудачной, потому что приходится согласовывать их действия и всегда, кто-то работает быстрее, а кто-то медленнее, но если этого не делать, то разработчик должен знать особенности разработки на каждой стороне.

Чтобы не строить архитектуру с нуля, можно воспользоватся готовыми JavaScript framework, например AngularJS, но тогда, Вам надо писать Controller, Routes и многое другое, повторяя уже существующий код на asp.net mvc.Главная проблема, всех javascript framework, это то, что Вам надо писать JS код

О, а если без JS

В последние время развивается тенденция написания JavaScript, используя типизированный интерпретатор или альтернативный язык
TypeScript — это возможность писать JavaScript, но в C# подобном синтаксисе. В чем тогда отличие TypeScript от IML:
  • не имеет готовых функций ( IML это декларативный язык, который описывает поведение, но не реализацию )
  • надо учить новый язык ( IML это C# )
  • надо устанавливать дополнительных утилит для формирования результирующего JS ( IML это C# )
  • не имеет интеграции с серверной частью ( IML адаптирован под asp.net mvc )


Ладно, чем же поможет IML?


IML предлагает набор методов для написания любых клиентских сценариев без JavaScript кода. Браузер работает по принципу событийной модели, и как показала практика, вариантов сценариев не так много.
Давайте рассмотрим стандартный алгоритм:
  1. Возбуждается событие у DOM элемента ( от имени пользователя или программным путем )
  2. Выполняется Action ( чаще всего это Ajax-запрос на указанный url )
  3. Обратный вызов по завершению Action, который запускает цепочку действий ( вставка полученных данных, работа с DOM, обновление CSS, применение JQuery plugin )


Покажи код, сразу все ясно будет

  Html.When(JqueryBind.InitIncoding)
           .Do()
           .AjaxGet(Url.Dispatcher().Query(GetCardsQuery  { Client = Html.Selector.Name(r=>r.Client)  }))
           .OnSuccess(dsl => dsl.Self().Core().Insert.WithTemplate(idTemplate.ToId()).Html())
           .AsHtmlAttributes()
           .ToDiv()


Лучше алгоритм

IML язык декларативный, поэтому его конструкции легко можно описать
  1. When InitIncoding — когда наступит событие появление элемента на странице
  2. Do — способ обработки поведения события ( Prevent Default, Stop Propagation )
  3. Action — ajax запрос на указанный url
    примечание: на примере для построения url применяется MVD, но можно и по старинке Url.Action(«controller»,«action», new { Client = Html.Selector.Name(r=>r.Client) })
  4. On — при удачном завершении Action, выполняем последовательность действий, на примере это вставка данных через template
  5. AsHtmlAttributes — упаковываем наш IML код в «теплый и надежный» RouteValueDictionary
  6. ToDiv — объявляем на странице, как Div ( можно в любой tag )


Проще всего по структурной схеме разобраться

image

Какие доводы ещё в пользу IML?

Если выделить основные преимущества IML, то:
  • No JS — эта фича является самой ключевой, потому что именно она выделяет IML на фоне других решений
  • Типизация — это эффект от первого пункта, Вам не надо больше изучать замыкания JS, думать что за «var» тут или сколько аргументов передать в function
  • Стандарт — декларативный язык на много проще использовать в команде
  • JSON ( Rest api ) и клиентские template — многие решения умеют работать в такой связке, но Incoding Framework имеет все средства из «коробки»


Вот, говорите у нас C#

Язык C# обладает, наверно, самым богатым функционалом и важно то, что все это можно использовать в рамках Вашей Razor страницы, то есть анонимные функции, лямбда и многое другое, что позволяет проводить рефакторинг Вашего приложения.
  • возможность разрабатывать свои Html extensions, которые потом повторно использовать на разных страниц.

    @Html.Project().Load(setting =>
                {        
                    setting.Template = Selector.Jquery.Id(tmplId);
                    setting.Url = Url.Dispatcher().Query(GetCardsQuery  { Client = Html.Selector.Name(r=>r.Client)  });
                })})
    


    примечание: код выполняет туже задачу, что была рассмотренная в первом примере
  • анонимные функции для построения MvcHtmlString, прямо во View
    @{
        Func<bool, mvchtmlstring=""> createComplete = (value) => 
                                                    Html.When(JqueryBind.Change)
                                                             .Do()
                                                             .AjaxPost(Url.Dispatcher().Push(new SomeCommand
                                                                {
                                                                     IsAdmission = each.For(r => r.IsAdmissionComplete)
                                                                 }))
                                                              .OnSuccess(dsl => // something )
                                                               .AsHtmlAttributes()
                                                               .ToCheckBox(value);
    }
    @using (each.Is(r => r.IsComplete))
    {
        @createComplete(true)
    }
    @using (each.Not(r => r.IsComplete))
    {
        @createComplete(false)
    }                             
    



Прямо таки все хорошо?


Приведу список отрицательных моментов Incoding Framework
  • Небольшое сообщество — для open source проектов, очень важно иметь единомышленников, но пока инструмент применяется в рамках
    нашей компании и несколькими знакомыми командами
  • Надо изучать — мы движемся в сторону уменьшения материалов, которые надо изучить для продуктивного использования Incoding Framework, но инструмент покрывает весь цикл разработки
  • Документация — за прошлый год было выложено 2 проекта на open source и опубликовано 20 постов в блоге, но пока ещё не все детали освещены


Заключение


В начале я написал, что наша компания занимается разными проектами, я подчеркнул, что круг решаемых задач, который стоит перед Incoding Framework очень большой. Многие скажут, что практически каждая фирма разрабатывает для себя свой framework, но мне кажется у нас получился инструмент, который может быть использован и другими командами.

P.S. Рад услышать отзывы и замечания
Влад Копачинский @vkopachinsky
карма
5,0
рейтинг 0,0
Ведущий разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (24)

  • +1
    А поверх OWIN никак не завести? Гвоздями приколочено к инфраструктуре ASP.NET и IIS?
    • +1
      На IIS ни как не завязано.
      Что касается компонентов framework, то:
      CQRS можно без проблем и для desktop проектов применять ( был опыт )
      IML это синтаксис для построения атрибутов в dom элементы, которому важно только формат возрощаемых данных, а как реализован Action не принципиально ( web api, HttpHandler, WCF )

      P.S. Будет интерес, я могу написать статью про интеграцию с OWIN
      • 0
        Интересно. У того же Mono большие проблемы с инфраструктурой ASP.NET (если вкратце, то тормозит), приходится пользоваться хостами фреймворков поверх HttpListener, а то и писать что-то своё, чтобы получить нормальную производительность, для интереса можете посмотреть на сравнительные результаты работы NancyFx в mono-fastcgi-server и моего хоста на базе evhttp.
        • 0
          Для работы framework требуется .net 4 и само собой C#, далее можно варировать, выбирая плафторму и как хостить.
          Некоторые части framework орентированны на asp.net mvc, но без них он будет работать, но как мне кажется, сперва стоит ознакомится с инструментов в иделаных для него услвоиях.
  • 0
    Первая картинка оскорбляет мои религи чувства разработчика.
    Против C# ничего не имею, но тот факт, что JS находится в клетке по меньшей мере неполиткорректен, а по большей — логически неверен.
    • +1
      В JavaScript, однако, есть вполне объективные недоработки, связанные с тем, что язык, по выражению его автора (Brendan Eich) делался «за 10 бессонных дней и ночей». Поэтому некоторые моменты продуманы плохо, есть и откровенные ошибки (которые признает тот же Brendan)

      Первая картинка оскорбляет мои чувства разработчика.

      На самом деле картинка несет ироничный характер и не направленна на оскорбления людей использующих JavaScript ( JS занимает львиную долю кода в incoding framework )

      по большей — логически неверен.

      Логика картинки в том, что бы заменить JavaScript при разработки на клиентской стороне с помощью C#, по этому не совсем пойму что не верно.
    • 0
      Таже песня что и с GWT, фреймоворк для лузеров которые боятся и ненавидят JS.
      • +1
        для лузеров которые боятся и ненавидят JS.

        ORM для лузеров, которые боятся и ненавидят SQL
        • –1
          Не совсем ясна связь между SQL и JS. Где последний отвечает ПОО парадигме, легко тестируется, регулярно обновляется. Что то я как-то не замечал этого за SQL. Ну во всяком случае ваша точка зрения ясна, вы ставите клиентские браузерные языки в один ряд с языком запросов к бд.
          • 0
            Не совсем ясна связь между SQL и JS.

            IML позволяет использовать C# вместо написания чистого JS, ORM абстрагирует от написания SQL.

            Ваша точка зрения тоже понятна, вы даже не смотрели, что я предлагаю, а решили написать вывод обо мне и проекте.
            • 0
              Не вижу особой разницы между вашей идей и GWT, если таковая есть, будьте любезны просветите.
              • 0
                Вас не смущает, что это разные платформы и технологии хотя бы?
                • 0
                  Концептуально, в чем отличия?
                  • +1
                    вы уходите в крайне абстрактные ( концептуальный уровень и т.д. ) вопросы, на которые даже ответить толком нечего.

                    Я не знаю про GWT и не буду его изучать, потому что это совсем другой стек, который не нужен в моей работе.

                    P.S. Я рад ответить на вопросы про проект, может какие то замечания по синтаксису, возможностям, но это должна быть конкретика, а не отсылка в то чем я даже занимаюсь.
                    • 0
                      Ну как хотите, GWT задолго до вас заключал за решетку JS, но последний до сих пор держится а вот о GWT давно уже завял. Мне казалось логичным прощупать конъюнктуру прежде чем браться за разработку. Продуктивность вашего подхода выглядит сомнительно при том что он может быть покрывает 80 процентов простых случаев, а вот в 20 оставшихся процентах придется рвать шерсть на одном месте. Как быть если понадобится использовать кастумный плагин jquery или промизы, пилить напильником?
                      • 0
                        что он может быть покрывает 80 процентов простых случаев, а вот в 20 оставшихся процентах придется рвать шерсть на одном месте.

                        Личный опыт использования? Есть сотни способов, как дописать новый функционал.

                        . Мне казалось логичным прощупать конъюнктуру прежде чем браться за разработку.

                        Пощупать разработку на других платформах?

                        Как быть если понадобится использовать кастумный плагин jquery или промизы, пилить напильником?

                        Extensions — blog.incframework.com/ru/extensions/
                        Разные вопросы — blog.incframework.com/ru/faq/

                        Если интересно, то приведу примеры кода, как можно вызывать Jquery plugin, свой метода поверх Selector и многие другие задачи.

                        P.S. Incoding framework это проверенный в десятках сложный приложений инструмент, конечно у многих разработчиков есть задачи с которыми я не сталкивался, но это относится к любому framework. Мы говорим только об одной части нашего framework, хотя там очень много и других ( Unit Test, cqrs, template и т.д. ), а Вы сразу ставите штамп «велосипед».

                        • 0
                          Пощупать разработку на других платформах?

                          Если концепция неудачна на java, python не представляю как она может быть удачна на .net

                          То что я видел в примерах jquery vs ваш фреймворк, с точки зрения написания современных приложений немного устаревает (я говорю касательно jquery). Использование jquery в виду усложнения логики среднестатистических приложений рассматривается как использование js низкого уровня примерно 5 лет назад. Сегодня гораздо удобнее использовать knockout.js или angular.js вместо излеваний тон js-кода низкого уровня. В связи с этим не вижу никакого позитивизма от использования вашего фреймворка, вы просто переносите спагетти код HTML/js(jquery) на сторону сервера RAZOR/c# dsl, какой от этого выигрыш?
                          • 0
                            Сегодня гораздо удобнее использовать knockout.js или angular.js вместо излеваний тон js-кода низкого уровня

                            Согласен, но статья ориентированна на тех, кто понял, что jquery и «скриптовый хардкод» это не удобно и сложно поддерживать и хочет, как то все структурировать. Jquery знают все, а конкретный js framework не каждый.

                            HTML/js(jquery) на сторону сервера RAZOR/c# dsl, какой от этого выигрыш?

                            1. Один язык
                            2. Интеграция с серверной частью ( font end тот же back end )
                            3. Все плюшки C#
                            4. Ещё раз, IML это набор возможностей ( уделите не много времени и ознакомитесь www.techdays.ru/videos/7236.html )

                            Могу добавить, что мне не нравится в использованием скажем angular.js, то что приходиться от части повторять модель серверной стороны ( mvc, mvvm и т.д. ) и писать JavaScript.
                          • 0
                            Для большего понимания IML стоит посмотреть blog.incframework.com/ru/power-selector/, а так же увидеть интеграцию с MVD blog.incframework.com/ru/model-view-dispatcher/.

                            P.S. Рад, что вопросы обретают конкретику.
  • 0
    IML это декларативный язык, который описывает поведение, но не реализацию

    IML это C#


    Я не совсем понял какая связь между императивным C# и декларативным подходом к программированию.

    Второе замечание, как альтернативу JS вы приводите TypeScript, простите за откровенность но кто, нафиг пишет на нем и кому он нафиг нужен? Другое дело Coffescript, Kotlyn, Scala или F# как замена JS, но не об одном из них вы не обмолвились. А они решают все заявленные вами претензии к JS.

    Мне кажется подобный вашему велосипед уже пыталась реализовать корпорация добра(GWT), но мне кажется этот проект можно уже достаточно давно сбросить со счетов.
    • 0
      IML это C# — идея в том, что описывать с помощью декларативного синтаксиса клиентские сценарии, а сам синтаксис выполнен на C#

      Coffescript, Kotlyn, Scala или F# как замена JS,

      Написать код, который будет работать в браузере можно, только через Coffescript и то по факту будет JavaScript. Все минусы TypeScript, так же относятся и к CoffeScript.

      • 0
        Написать код, который будет работать в браузере можно, только через Coffescript и то по факту будет JavaScript
        На в чем проблема, если ваш кода валидный и вы используете sourcemap?
        • 0
          Я предлагаю решение со своими плюсами и минусами, которые описаны в статье.
          IML это часть Incoding Framework, который покрывает весь цикл разработки и позволяет интегрировать каждую часть между собой, а вы говорит о языке, который позволяет писать JavaScript иначе, но ни как не связан с asp.net mvc.

          Я не отрицаю, что на Coffescript пишут JavaScript приложения, но я предлагаю альтернативный вариант для тех, кому больше нравится C# и декларативный подход с готовым набор возможностей.
  • 0
    del

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.