Лапшекодим валидацию, или запрещаем вводить неправильные данные?
У нормальных поставщиков контролов оно уже давно так и есть.
А кто сказал что МС - нормальный поставщик контролов? Они делают только то что нужно лично им.
Поэтому во всех нормальных конторах юзаются всякие девэкспрессы и прочие контрол-паки. Да и от самой МС есть какие-то бесплатные - Fluent чего-то там.
2. Кто программировал усложнял СПЕЦИАЛЬНО.
А если вскроется? Приходит какой-нибудь мурр на проект, а там зелёные сеньёры. Он такой про себя - "хыхыыы, все лохи, а я семизнак... щас устроим им тут театр незаменимого актёра". Ну типа срублю второй семизнак. А тут заказчик решил вдруг со стороны экспертизу заказать, или просто другой знакомый семизнак на код взглянул и выдал - "да вас тут за нос водят, бутерброд из паттернов на ровном месте делают, чтобы никто не разобрался". Что тогда?
заказчик решил вдруг со стороны экспертизу заказать
А что покажет сторонний аудит? А аудит покажет повышение производительности на 30 процентов! )))
Не нравится стиль? Пусть нанимают этого самого тестера или QA, он разберётся или напишет с нуля.. если сможет)
А захотят уволить? А у тебя внезапно накрылся комп и все флешки с документацией полетели, такое иногда бывает.
Потом вместе идут читать контракт, который заключили в самом начале, обязанности и кто кому платит неустойки.
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
флешки с документацией
И перфокарты с исходниками))
Смешно? пример из жизни, уволили человека - он унёс с собой всё что можно.
будешь сейчас про сегодняшние реалии рассказывать? про резервные копирования в облака итд итп, ну дак и контракты каждые пару лет обновляются дополняются, а пользовательские соглашения вообще каждые пару месяцев, не? прокол, юристы латают, переписывают пункты, не?
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
Ну т.е. пишется код для вью модели или там расширение для разметки, или спецконтрол, или ещё как-то, который будет через рефлексию вытаскивать данные из атрибутов?
Волшебства тут нет - если что-то запихано в атрибуты, и надо достать, то пиши костыли-портянки. А куда эти портянки поместить - дело десятое.
если что-то запихано в атрибуты, и надо достать, то пиши костыли-портянки.
Не вижу никаких проблем, написал один раз и пользуйся сколько хошь. И не так уж тяжело атрибуты пользовать.
Хочу я глянуть как будете запихивать контролы с валидацией в проперти грид
чтобы не плодить кучи валидирующего кода, а сразу привязать границы
Вообще то вопрос был совершенно для другого. По ответу сразу видно на каком уровне обдумывается зашита/ наступление
- отделение
- взвод
- рота/батарея
- батальон/дивизион
- полк
...
- армия
Вопрос был какого смешивать атрибуты и контролы с ограничениями?
Представьте что есть хотя бы пяток формуляров в котором используются одни и те же данные но в разной форме.
То бишь не всё так однозначно
Вопрос был какого смешивать атрибуты и контролы с ограничениями?
Представьте что есть хотя бы пяток формуляров в котором используются одни и те же данные но в разной форме.
То бишь не всё так однозначно
В чём проблема? В одном случае для каждого привязываемого свойства вы в байндинге будете указывать валидатор. В другом (мой вариант) - привяжете Min и Max к соответствующим свойствам контрола. NumericUpDown юзается везде, где есть числа. Т.е. он подходит для любых чисел, не только с плавающей запятой. И не важно, как и в каком виде он в формуляре. А вот для валидации обычно юзаются валидаторы для каждого типа чисел - типа DoubleValidation, IntValidation и т.п. Хотя, по идее, можно и один громоздкий общий валидатор написать. Но суть в том, что у меня привязки аккуратные и читаемые - Value, Min, Max, а с валидаторами - портяка из многословного XAML с указанием валидаторов для байндингов.
В другом (мой вариант) - привяжете Min и Max к соответствующим свойствам контрола.
Ах вот о чём. Мне как-то тяжело представить что кто-то будет смешивать данные с ограничениями/
Както не хочется видеть подобное, да и SRP тоже не хочет 
ACount
ACountMin
ACountMax
Code1
Code1MaxLength
Date
DateFormat
BCount
BCountMin
BCountMax
Ну там полно свойств для чисел со стрелочками вверх-вниз - тот же NumericUpDown. В чём проблема? У этого грида нет свойств Min и Max для чисел? Тогда это грид хреновый.
Основное отличие вашего подхода от моего - у вас либо идёт преобразование данных атрибутов через промежуточную модель (в неё вытаскиваются данные атрибутов), либо через расширения разметки, либо ещё как-то. Т.е. в любом случае - полного медленного кода (рефлексия) для каждого байндинга. А у меня - привязка напрямую к уже готовым свойствам, безо всякой возни с рефлексией, конвертерами и прочим лишним кодом.
Както не хочется видеть подобное, да и SRP тоже не хочет
ACount
ACountMin
ACountMax
Code1
Code1MaxLength
Date
DateFormat
BCount
BCountMin
BCountMax
Наоборот отлично, и уже сгруппировано всё.
А я не хочу видеть портянку атрибутов к каждому свойству. Заметьте, тут они ещё простые - сразу пошли строки задавать. А ведь могли бы начать указывать все параметры атрибутов, как это будет в реальном приложении с мультикультурой и прочим. Тогда для RangeAttribute будет минимум 5 параметров, для DisplayAttribute - минимум 3 (а можно и 5-7), и так далее.
Тогда это грид хреновый
Для начала хорошо бы разобраться в принципе работы проперти грид
https://www.c-sharpcorner.com/article/using-property-grid-...
Наоборот отлично, и уже сгруппировано всё.
Конечно отлично, вместо 4 строчек исключительно данных иметь 10 разного мусора
ACount
Code1
Date
BCount
При этом не зная какие ограничения для чего.
Вот как мне узнать "автоматически", какие ограничения имеет ACount?
как это будет в реальном приложении с мультикультурой
А как это может влиять на количество атрибутов?