Pull to refresh

Comments 14

Когда не умеешь в валидацию на клиенте.

Вы извините за, возможно, резкость, но вам вью зачем? Чтобы организовать биндинг данных?
Не нужно вам для валидации отправлять все действия в форме на сервер, и ждать ответа.
Поверьте умею. Но тогда я должен настраивать валидацию два раза. Первый раз на уровне Entity а второй на клиенте. Eсли валидация завязана на длину полей в базе, или пустое значения, то конечно перетащить не сложно, а если логика более сложная и требует обращения к базе?
Здесь все единообразно и настраивается в одном месте.

Вы ещё скажите что модель MVC мешает вместо алертов делать изменение класса инпута чтобы бордер красным был и Вы уверены, что сейчас описывали проблемы модели, а не конкретной кривой реализации, а то связанность модели, контроллера и представления можно сделать кроме того что по-разному, так ещё связанность будет разной в разных реализациях. А так очень похоже на «было криво» заменили на «свой более удобный велосипед(собственную реализацию работы фронта)» и при этом считаете, что то что было раньше — это косяки или ограничения патерна.

Сама модель не мешает, просто классический подход в том что нужно отправить форму на сервер, что бы увидеть ошибки валидации, а перезагрузка формы сжирает трафика в разы больше чем валидация.
В том то и удобство Single Page Application что сайт загружается один раз, а далее вся работа идет через Ajax асинхронно. К сожалению такой подход не возможен в моем случае. Поэтому приходится использовать загрузку каждой страницы отдельно. Но далее страница работает без перезагрузок используя возможности VueJs. Вполне стандартным для этого фреймвока способом.
Такой подход получается чуть проще (нет ни каких сборщиков роутеров и пр. ) достаточно подгрузить базовую библиотеку через cdn
Клиент с медленным соединением не будет доволен таким подходом. Вы решаете свою (несущественную) проблему и убиваете UX. Хотите сделать единообразно — опишите валидацию и генерируйте для клиента и сервера.
Я рассматривал такой подход для стандартных случаев когда валидация заключаться в проверке длины и тп. Только кода получится больше. И он будет на много сложнее.
Да чем собственно клиент может быть не доволен.
Сейчас он жмет на кнопку сохранить и получает список ошибок через минуту например.
В данном случае он успеет нажать кнопку сохранить не дожидаясь валидации и так же через минуту, а то и раньше увидит красные рамки вокруг невалидных полей.
Выходит что вы все равно шлете всю модель на сервер для валидации, а при подходе к валидации на клиенте и сервере у вас с клиента будут летать только проверки на необходимые поля и, скорее всего, полная валидация, при отправке результирующей формы, которая будет скорее всего валидна, не удивит пользователя миллионам красных полей или попапов в вашем случае.
Да именно так.
И полагаю, что при минимальной оптимизации нагрузка на сервер не сильно возрастет ибо json с данными как не крути на порядок меньше Html формы отображающей эти данные.
Автору статьи нужно хорошо поработать над пунктуацией и орфографией, а после уже публиковать её. Вы же хотите, чтобы Ваши статьи было приятно и интересно читать, тогда, пожалуйста, постарайтесь над этим поработать.
Увидел заголовок и ожидал чего-то полезного (с коллегами никак не может решиться на выделение фронта в отдельный проект на vue.js). А в итоге… ерунда какая-то. Прочитав такую статью — хочется забиться в угол и больше никогда не смотреть в сторону vue.js, а спокойно кодить на ламповом C#, сидя в удобном кресле, с надписью «asp.net core».

Если по существу — зачем это всё? Если вы хотите сосредоточиться на C#, то и надо это делать. Подобные, да и куда более сложные, задачи прекрасно решаются штатными средствами asp.net mvc + razor + jquery unobtrusive validation, с практически полным отсутствием js-кода, применяя ajax-формы (спасибо в asp.net core с tag-хелперами всё это стало прям красивым и удобным). Даже штатные атрибуты валидации модели (data annotations) дадут вам базовую клиентскую валидацию, с последующей валидацией модели на сервере. В итоге все счастливы — кода минимум, базовые проверки идут на клиенте (да, с выделением красными рамочками и прочей любой красотой), на сервер модель приедет уже примерно ровная, и допроверяв её — возвращаем результат, как нам удобно. Сплошной C#, исходника на эту же задачу наверное в 3 раза меньше, и всё ровно, красиво, по рекомендациям. Ну и главное — логика вся пишется в одном месте.

А так, не зная Vue.js на должном уровне, зачем вообще лезть в него?

Пример может не лучший, но первый попавшийся из гугла:
damienbod.com/2018/11/09/asp-net-core-mvc-ajax-form-requests-using-jquery-unobtrusive
Зачем люди придумали Vue(angular, react) когда то же можно сделать на jquery?
Для простой формы, да может быть у вас кода будет меньше.
Если форма будет иметь много полей, таблицы и какую то элементарную логику типа скрыть часть полей по условию и все такое не уверен.
В моем примере дальнейшее наращивание количества полей не добавит много кода.
Зато всю «отрисовку» можно делать используя Vue, что поверьте значительно удобнее (он для того и создан). Короче пример минимизирован для показа элементарных возможностей.
Когда же надо будет нарисовать действительно сложную и навороченную форму можно и компонентов добавить и webpack подключить и роутер ну короче использовать всю мощь Vue.
Зачем лезть в Vue.js? Что бы узнать его на должном уровне.
Ну кроме всего прочего следующий проект надеюсь мы будет Single Page Application.
У вас написано «Мы в программисты С# и не знаем js в нужном объеме» — при таком начале как-то странно пытаться использовать Vue.js, предполагающий как раз хорошие знания js.

Правильнее было бы как раз не смешивать мух с котлетами, а отделить фронт от бэка, отдать его разработку специалисту по js, а на бэке оставить C#, предоставляющий API.
Вот тогда будет то, что имеет смысл и позволит в дальнейшем расширять и наращивать функционал. Если наворотить как предложено в этом посте, смешав Vue.js с MVC и Razor — будет только хуже, особенно с ростом функционала.

А так у вас с одной стороны «Зато всю «отрисовку» можно делать используя Vue», а с другой «При каждом изменении формы Vue отправляет на сервер все изменения». Очень странное сочетание. Об это кратко и ёмко указал автор первого комментария.

И тут не очень понятно, что такое «отрисовка» в случае использования Vue.js. Шаблон у вас написан на html + razor + байндинг модели от Vue.js. Просто убрав отсюда Vue.js и применив например ajax-формы — получим тоже самое, абсолютно, но без js-кода.
К сожалению мои знания js и vue далеки от идеала я его только изучаю.
Учитывая, что расширения штата что бы иметь отдельного программиста для фронта у нас не предвидится хочется предложить коллегам работающий и простой шаблон с которого можно начать делать для начала хоть простые формы.
А так у вас с одной стороны «Зато всю «отрисовку» можно делать используя Vue», а с другой «При каждом изменении формы Vue отправляет на сервер все изменения». Очень странное сочетание.

Мне не кажется странным. Vue строит выпадающие списки в том числе связанные, динамически подключает нужный CSS и прочее. А на сервер отправляет для валидации (что бы не грузить сервер можно использовать «ленивый биндинг» отправляющий поля при потере фокуса.)
Это разные задачи, но они обе важны.
Шаблон у вас написан на html + razor + байндинг модели от Vue.js

Razor здесь занимает минимум места, только для передачи констант.
На Html написан шаблон vue. Это стандарт в данном случае.
Как я уже писал Vue в данном примере кроме биндинга строит выпадающие списки и подключает CSS по условию. Может естественно больше. Просто хотелось продемонстрировать базовые часто встречающиеся задачи.

unobtrusive validation и стандартные формы + свои тэг-хелперы это очень мощный инструмент, особенно когда вы генерируете CRUD по быстрому для редактирования таблиц с помощью Scaffolding.
Vue это офигенная тема, но его стоит вставлять только там где сложная логика обработки форм, от выбора одного элемента на форме зависит состав выбора другого, например, и ещё такой момент нужно учесть — как часто нужно делать то что вы делаете? если редко, логин/пароль например, то можно обойтись стандартной валидацией. если это какаято бизнес-форма с которой часто люди работают, то конечно нужно поставить удобство пользования выше удобства разработки. а с таким подходом как у вас можете вобще посмотреть в сторону blazor, там вобще без JS можно обойтись
Sign up to leave a comment.

Articles