Лапшекодим валидацию, или запрещаем вводить неправильные данные?
Так это для форм? Я с ними сто лет не работал уже.
Ладно-ладно, нравится писать потянки с атрибутами и доставанием данных из них - пожалуйста. Я, поработав так и этак (и подостовав, и просто в обычных свойствах всё похранив), решил, что если как-то не оговорено особо, буду юзать обычные проперти. Для меня это проще, чем обвешиваться костылями разных расширений.
А узнать ограничение на свойство можно как и обычно - посмотрев код. Что в случае с атрибутами, что в моём варианте обычно все данные о свойстве влезут в один экран.
Так это для форм?
Для впф есть тоже самое но изначально, да были винформс
и доставанием данных из них
Доставание может делаться одни единственный раз, а потом просто использоваться.
А узнать ограничение на свойство можно как и обычно - посмотрев код
Разговор то не о человеке, а о машине. Она как то код не может посмотреть
Для меня это проще
А для меня проще - это когда проекту и команде будет проще.
и доставанием данных из нихДоставание может делаться одни единственный раз, а потом просто использоваться.
Ну тогда как я и говорил - вы заводите промежуточную модель для хранения данных атрибутов в виде обычных пропертей. А у меня это сразу так хранится, безо всякого доставания.
Для меня это прощеА для меня проще - это когда проекту и команде будет проще.
А я согласен. Есть люди и команды, привыкшие обвешиваться кучами расширений для всего и уже не мнящие работу без всего этого багажа, забыв, что можно изначально сделать проще. У таких новый проект начинается с подключения десятка разных расширений для атрибутов, разметки, базовых классов для каждой модели с кучей реализованных интерфейсов. Без этого не заводится. Придя в такую команду, придётся подстраиваться, но для себя я делаю по-простому, как я выше объяснял.
вы заводите промежуточную модель
Никто ничего не заводит. Когда надо тогда и берём
А у меня это сразу так хранится
А сколько при этом получается минусов?
Интеллисенсе не пользуете для доступа к данным?
Количество шагов для добавления правила валидации не считали?
А то что все зависимости от модели данных будут считаться измененными - это видимо вообще в расчет не принимается.
что можно изначально сделать проще
Это так кажется с колокольни ефрейтора, как выше уже пытался объяснить.
Придя в такую команду, придётся подстраиваться
Ну это как бы само собой разумеется, работа в команде и работа одиночки совершенно разные вещи.
вы заводите промежуточную модельНикто ничего не заводит. Когда надо тогда и берём
Вы можете привести пример, как вы берёте в той же разметке XAML значение свойства атрибута какого-нибудь свойства модели (не модели представления)?
как вы берёте в той же разметке XAML значение свойства атрибута какого-нибудь свойства модели
Зачем? Валидация делается на других принципах
Зачем валидировать что-то, что пришло из контрола, который в принципе не допустит неправильных данных? Вот есть у вас контрол, где можно ввести числа от 0 до 10, но вы будете ещё дополнительно проверять, а не пришло ли с него чего-то больше 10 или отрицательного?
И ещё - вы данные в каждом слое валидируете?
И где вы показываете все эти error messages, которыми там обильно удобрили все ваши данные? В тултипе? А зачем? Человек должен навести на подсвеченное неправильным поле, дождаться тултипа, прочитать портянку... А если сразу не давать вводить неправильные данные?
[StringLength(50, ErrorMessage = "No more than 50 characters")]
[Display(Name = "Name")]
Зачем вот это "50" и сообщение об ошибке, если можно просто заблочить текстбокс от ввода строк длиннее 50 символов?
Ну и в реальности применение этого атрибута будет выглядеть не так аккуратно, как здесь, а будет обвешано ещё всякими указаниями на ресурсы и ключами в этих словарях. Мы же не на один штатовский рынок работаем, когда все строки можно захардкодить и наплевать на всё остальное, и не аккуратную рекламную писульку делаем, как у него на заглавной странице проекта, а нечто реальное разрабатываем?
Вы, может, не понимаете, но с моей точки зрения, достаточно иметь просто набор нормальных контролов, которые делают все основные валидации для своего типа данных внутри себя. А вам нужно только привязать условия этих валидаций. Таскать данные для валидации между слоями - это ваш метод. Вы своими расширениями из вьюхи лезете в модель через вьюмодель, там на каждый чих дёргается рефлексия с кучей методов и селекторами по имени свойства и прочим параметрам. А потом предъявы к WPF, что это гриды с кучей значений тормозят.
А ещё заметили, что у него там не классический MVVM, а просто модель представления и вьюха. А где основная модель? А как правило именно у основной модели (т.е. модели из области бизнес логики) стоят эти атрибуты. И как он будет прокидывать атрибуты из модели во вью модель?
Блин, да там половины кода для нормальной работы нет! Его пример вообще заведётся в нормально приложении? Где реализация INotifyPropertyChanged?
У чела лысый пример без одного слоя и самого нужного в MVVM интерфейса, а также простейший пример использования атрибутов. В реальности всё будет куда массивнее, запутаннее и некрасивее. Тогда как в моём случае вы просто делаете больше свойств, но используете простейшие привязки и безо всяких портянок, вызывающихся на каждую привязку.
Тут в соседней теме Мурр убивается за 10-15% производительности. А здесь на привязках готов потерять её в разы, как и вы.
Зачем вот это "50" и сообщение об ошибке, если можно просто заблочить текстбокс от ввода строк длиннее 50 символов?
Очень плохо для пользователя. Он не понимает отчего иногда данные можно ввести а иногда нет. Или вот скопировал я данные в поле - А их кто то откусил.
Или вот можно ввести только 5000 символов в сообщение - очень хорошо знать сколько мне еще осталось
И где вы показываете все эти error messages
Как предусмотрено в конкретной реализации
https://docs.telerik.com/devtools/wpf/controls/radcardview...
Могу кстати, поздравить со шнобелевской премией - ещё никто из разработчиков библиотек не додумался делать предлагаемый способ валидации. Может патент еще оформить и всем продавать?
все строки можно захардкодить
Вероятно кто то просто не в курсе как делается локализация текста в атрибутах.
но с моей точки зрения, достаточно иметь просто набор нормальных контролов, которые делают все основные валидации для своего типа данных внутри себя.
Просто не для всех задач подобный подход будет приемлем.
А ещё заметили
не смотрел подробности - десктоп давно не интересует
Зачем вот это "50" и сообщение об ошибке, если можно просто заблочить текстбокс от ввода строк длиннее 50 символов?Очень плохо для пользователя. Он не понимает отчего иногда данные можно ввести а иногда нет. Или вот скопировал я данные в поле - А их кто то откусил.
Или вот можно ввести только 5000 символов в сообщение - очень хорошо знать сколько мне еще осталось
Если что, мой подход и не запрещает вам всё это иметь и показывать. Только костылить с атрибутами и сложными привязками не надо.
Как бы, нормальный контрол как предоставляет возможность привязать границы вводимых данных и отобразить сообщение об ошибке дефолтно, так и приделать что-то своё. Да собственно даже базовые контролы в WPF делают то же самое - рамочку красную кто вокруг рисует, если что-то не так? Сам контрол и рисует. Правда опираясь на значение валидатора.
Как предусмотрено в конкретной реализации
https://docs.telerik.com/devtools/wpf/controls/radcardview...
Кстати, а что, MAUI уже релизнулся? Или это Телерик сами, с нуля свой мультиплатформенный фреймворк накропали? Оно хоть нативное, или опять через браузерный компонент джаваскриптизируют и веб-разметку насилуют?
