JavaScript-приложение, или зачем нам Razor в ASP.NET MVC?

[kuber]

Понятно, что нет необходимости использовать Razor если вы используете Web API, но если вы используете ASP.net MVC, то Razor просто шикарен и я не встречал шаблонизатор лучше.

[AlexanderByndyu]

Речь скорее о том, что мы ушли от шаблонизатора Razor и перешли к JS-шаблонизаторам в отдельном JS-приложении. Если мы создаем ASP.NET MVC приложение и рендерим с помощью него HTML, то используем Razor.

[kuber]

Я так и понял.

[IL_Agent]

Не думал, что напишу это, но JavaScript победил. Мы перестали использовать Razor для создания веб-приложений.

Исходя из названия статьи и первых её фраз можно было подумать, что вы собираетесь утверждать о ненужности server-side rendering как такового :)

[AlexanderByndyu]

Надеюсь продолжение статьи развеивает это впечатление.

[IL_Agent]

Да, противоречит ему

[AigizK]

У, такими темпами скоро дойдете до того, что бекэнд будет не на ASP.NET ))

[AlexanderByndyu]

От .NET мы вряд ли откажемся, но скорее всего перейдем на кросс-платформенную версию. Уже пробовали компилировать и запускать проекты под Linux, выглядит многообещающе.

[justmara]

Главное — не пытайтесь портировать имеющиеся. На данный момент это та ещё боль.

[ruslanys]

А на Node.JS, например)

[AlexanderByndyu]

В Facebook уже обсудили эту тему www.facebook.com/alexander.byndyu/posts/946206085463803?comment_id=946214718796273&comment_tracking=%7B%22tn%22%3A%22R%22%7D

JavaScript с обеих сторон не отменяет того, что цели у бэка и фронта разные и среды исполнения разные.

[Razaz]

Нода хороша только на IO. Compute — не ее. А .Net дает и то и другое. github.com/aspnet/benchmarks. Либо Java/Scala либо .Net.
17 декабря уже Kestrel perf target #1million

[AigizK]

А БД какую используете или собираетесь использовать, если будете еще на Linux запускать? И ваша команда вроде практиковала CQRS подход, не отказались еще?

[AlexanderByndyu]

Из БД у нас больше всего используются MSSQL, PosgtreSQL, MongoDB, Sphinx. Три последние мы хостим на Linux.

Да, мы практикуем CQRS. Нам нравится, пока альтернативы не нашли :)

[SergeyRodyushkin]

А не могли бы вы рассказать, как в проектах с подобной архитектурой реализуется валидация правил, локализация и подобные вещи, имеющие отношение как к UI, так и к бизнес-логике? В каком виде приходят сообщения об ошибках?

[Shablonarium]

Подпишусь на этот вопрос.

[AlexanderByndyu]

Сергей, вопросы понятные и актуальные. Я собираю информацию по нашим проектам, чтобы рассказать вам общие выводы.

[osharper]

Вот да, тоже об этом хотел спросить. По мне, так локализацию лучше как раз отдать рейзору и бэкэнду, чем тому же ангуляру.

[AlexanderByndyu]

> локализацию лучше как раз отдать рейзору и бэкэнду, чем тому же ангуляру

Какая разница где писать переводы? Механизмы выбора перевода одинаковые. Из текста по ключу выбирается перевод в зависимости от локали.

[marshinov]

Локализацию можно использовать из *.resx-файлов. Для этого потребуется сгенерировать часть js-кода со стороны .NET и отдать отдельным файлом. Для большинства проектов оверхед на один запрос не значительный, работает хорошо. Файл создается только один раз при старте приложения или встраивается в билд-процесс.

Для валидации так-же можно генерировать js-код на сервере, используя DataAnnotations. В случае с кастомной валидацией, которая нужно описывать в виде императивного кода — ничего не поделаешь — нужно дублировать код.

Если хочется совсем упороться, то можно посмотреть в сторону Roslyn и конвертировать C#-код валидации в JS. Есть вот такой пример конвертирования C# в С++ от mezastel. Учитывая, что в ES6 есть поддержка лямбд подобная задача может быть интересна с исследовательской точки зрения. В коммерческой разработке применять такие решения скорее всего дороговато.

[AlexanderByndyu]

> реализуется валидация правил

Валидация реализуется на front-end и back-end приложениях.

Часть валидаций относятся только к front-end, например, пока поле не заполнено не нажимать кнопку.

Часть валидаций одинаковые для front и back, например, валидация формата телефона или бизнес-правило не добавлять в корзину Х, если там уже Y. В этом случае логика реализуется и на front и на back.

Часть валидаций только на back, например, является ли логин уникальным.

По сути ничего не изменилось со времен, когда мы использовали только ASP.NET MVC. Единственная разница это отсутствие атрибутов валидации, которые можно было вешать на модель. Но это почти не заметно в работе, т.к. эти атрибуты покрывают обычно самую простую валидацию: пустные поля, маска для поля и т.п.

> локализация

Локализация front-end делается стандартными средствами. Можно для примера посмотреть как сделана локализация jQuery UI. Есть файл с переводами, есть механизмы выбора переводов из этого файла. Очень похоже на то, как сделаны переводы через ресурсы в .NET

> В каком виде приходят сообщения об ошибках?

Они приходят ответом на Ajax-запрос, а формат такой, какой будет согласован. Обычно это просто JSON.

[SergeyRodyushkin]

Спасибо за развёрнутый ответ. Поясню, моя цель, в общих чертах, состоит в уменьшении связности между backend и frontend для параллельной разработки. Есть общее соглашение о формате данных, но в частностях хотелось бы оставить некоторую свободу — например, чтобы изменение правил валидации не влекло за собой необходимость одновременной модификации frontend. Пока я склоняюсь к публикации неких метаданных с backend, подобно IClientValidatable-правилам. Сначала я хотел избежать необходимости локализации и клиента, и API, но, похоже, это мечты :)