Насчет примера - так я как раз и говорю, что наличие поддержки async в валидаторе сомнительное дело. Понятно, что можно написать обращение к БД или API и синхронно, но это через API валидации не закроешь.
// involve custom userService for specific logic
v.ErrorIf(async m => await userService.IsUserExistAsync(m.Email),
"User already registered", m => m.Email);
Бегать в базу при валидации дорогое удовольствие (хотя бы потому, что после этого запросто может быть еще одна проверка, но уже без обращения к БД. И тогда будет просто трата ресурсов).
Тут вроде как речь про валидацию, а в примере проверка бизнес правила. Как мне кажется, стоит разделять валидацию и проверку бизнес правил. В результате, запрос, который не проходит валидацию, всегда не сможет ее пройти. А вот для бизнес правил результат проверки зависит от текущего состояния системы.
И такое разделение хорошо ложиться на CQRS: command и query валидируется (правлиа можно положить рядом с ними), а бизнес правила проверяются в соответствующих сервисах.
а работник не может использовать созданный им код без разрешения работодателя.
Мне всегда было интересно что это значит. Ну вот работик передал код, где есть строка c "for (i=0; i<max; i++) { ... }". Значит ли что он не может больше писать циклы for? :)))
Утрирую конечно, но вопрос в том, с какого момента начинается "запрещенный к использованию" код? Да и вообще что это такое?
Ок, давайте по порядку тогда
1) По поводу «текущего вида»: это RC2. Считать текущим видом RC1 после 17 мая неправильно. Более того, с января (как я помню) разработчики рассказывали про грядущие изменения. И для кого это произошло внезапно — ну ССЗБ. Более того еще есть и open source на GitHub.
2) По поводу «неизвестно когда»: разработчики обещали RC2 в мае, RTM в конце июня. Первую часть обещания они сдержали. Ждем вторую.
Посмотрите на API Амазона (не S3, а все остальное что там есть). Все эти API — самые уродливые XML чудовища, сделанные в RPC-стиле. Но вы же не будете отрицать насколько это API успешно?
Успешно не API, а сервисы, доступ к которым оно дает. В этом случае будут пользоваться даже самым ужасным API (т.к. вариантов нет). Больше похоже на «мыши плакали, кололись, но продолжали жрать кактус».
Да, верно оговорился — речь была про замену grunt на gulp. Спасибо что заметили.
Мне не совсем ясно почему всегда должны различаться таски для паблиша и разработки. Но тем не менее кроме биндинга в gulpfile.js есть scripts: prepublish в project.config
> а логика работы таки да, должна быть в контроллере.
Давайте посмотрим шире и уйдет от элементарных демо-приложений из 1-2 контроллеров. Как правило у вас вы будете создавать n-tier (ну или onion) решение, где у вас будет отдельный бизнес-слой. Веб-приложение вообще в этом случае это просто уровень UI. И чем меньше в нем именно бизнес-логики, тем лучше (для сопровождения и модификации в дальнейшем).
Я даже склонен рассматривать модели MVC приложения как ViewModel в рамках всего приложения. Т.е. контроллер знает что за данные запросили, знает где их взять (в каких сервисах) и формирует некую модель для данной страницы (ведь не всегда то, что надо отобразить 1 в 1 совпадает с моделями BL, не редко это набор из BL).
> но все равно нет описания о том как использовать bower, grunt, css процессоры
Все еще впереди :) Кстати, в последних сборках в проект уже по умолчанию включается gulp, а не bower.
> поставить nodejs + npm это не абы какая проблема
Разумеется не проблема. Я же комментировал вашу реплику о том, что «устанавливается проще». В данном случае те же телодвижения: npm и добавление тега script. А вот если есть причина не ставить у себя node — по сути в клик ставим на Azure (можно взять free план если нагрузка не большая).
А скажите, чем проще установка, если используется тот же npm и добавление тега script? Это локально, а у Vorlon.js еще есть деплой в Azure. :)
Из плюсов weinre стоит отметить timeline.
Из минусов нет network (там только для ajax), modernizer, и вообще возможности добавить свой модуль (а значит больше шансов что как раз Vorlon.js будет активнее развиваться).
А, не заметил это с ходу. :) Ну тогда мое исходное утверждение получается верно — при использовании инициализаторов сборка класса происходит в промежуточной переменной. а уже потом присвоение в заданную. Соответственно и насчет инициализации массива тоже самое (см. мой первый комментарий). Не ясно тогда о чем спор :)
Насчет примера - так я как раз и говорю, что наличие поддержки async в валидаторе сомнительное дело. Понятно, что можно написать обращение к БД или API и синхронно, но это через API валидации не закроешь.
А только меня напрягает такой код как в примере.
Бегать в базу при валидации дорогое удовольствие (хотя бы потому, что после этого запросто может быть еще одна проверка, но уже без обращения к БД. И тогда будет просто трата ресурсов).
Тут вроде как речь про валидацию, а в примере проверка бизнес правила. Как мне кажется, стоит разделять валидацию и проверку бизнес правил. В результате, запрос, который не проходит валидацию, всегда не сможет ее пройти. А вот для бизнес правил результат проверки зависит от текущего состояния системы.
И такое разделение хорошо ложиться на CQRS: command и query валидируется (правлиа можно положить рядом с ними), а бизнес правила проверяются в соответствующих сервисах.
Мне всегда было интересно что это значит. Ну вот работик передал код, где есть строка c "for (i=0; i<max; i++) { ... }". Значит ли что он не может больше писать циклы for? :)))
Утрирую конечно, но вопрос в том, с какого момента начинается "запрещенный к использованию" код? Да и вообще что это такое?
«Пора убить веб» habrahabr.ru/post/338880
Забавно ведь :)
А «красота» разве не эмоция? Чем плохи эмоции? Ваше раздражение вот тоже эмоция. Причем она дала букв больше, чем «красота» :)
Выдохните, проведите без политики недельку или две. А то везде она вам мерещится.
А с исходным посылом я согласен — «красота». Визуально презентация мне понравилась. И пусть некоторых политически ангажированных от этого плющит.
1) По поводу «текущего вида»: это RC2. Считать текущим видом RC1 после 17 мая неправильно. Более того, с января (как я помню) разработчики рассказывали про грядущие изменения. И для кого это произошло внезапно — ну ССЗБ. Более того еще есть и open source на GitHub.
2) По поводу «неизвестно когда»: разработчики обещали RC2 в мае, RTM в конце июня. Первую часть обещания они сдержали. Ждем вторую.
Это как? Вернутся в прошлое и выключат свет? )
Успешно не API, а сервисы, доступ к которым оно дает. В этом случае будут пользоваться даже самым ужасным API (т.к. вариантов нет). Больше похоже на «мыши плакали, кололись, но продолжали жрать кактус».
Мне не совсем ясно почему всегда должны различаться таски для паблиша и разработки. Но тем не менее кроме биндинга в gulpfile.js есть scripts: prepublish в project.config
Давайте посмотрим шире и уйдет от элементарных демо-приложений из 1-2 контроллеров. Как правило у вас вы будете создавать n-tier (ну или onion) решение, где у вас будет отдельный бизнес-слой. Веб-приложение вообще в этом случае это просто уровень UI. И чем меньше в нем именно бизнес-логики, тем лучше (для сопровождения и модификации в дальнейшем).
Я даже склонен рассматривать модели MVC приложения как ViewModel в рамках всего приложения. Т.е. контроллер знает что за данные запросили, знает где их взять (в каких сервисах) и формирует некую модель для данной страницы (ведь не всегда то, что надо отобразить 1 в 1 совпадает с моделями BL, не редко это набор из BL).
> но все равно нет описания о том как использовать bower, grunt, css процессоры
Все еще впереди :) Кстати, в последних сборках в проект уже по умолчанию включается gulp, а не bower.
Разумеется не проблема. Я же комментировал вашу реплику о том, что «устанавливается проще». В данном случае те же телодвижения: npm и добавление тега script. А вот если есть причина не ставить у себя node — по сути в клик ставим на Azure (можно взять free план если нагрузка не большая).
Из плюсов weinre стоит отметить timeline.
Из минусов нет network (там только для ajax), modernizer, и вообще возможности добавить свой модуль (а значит больше шансов что как раз Vorlon.js будет активнее развиваться).
Оригинал: