Страницы: 0 | (9) | 20 | показать все
В ответ на:
или не понятно конкретно то, что ты выделил?
То что выделил.
В ответ на:
но в WPF слишком много кода для такого простого случая.
Ты один раз напишешь конвертер и можеш его использовать в десяти местах, а используя входящие параметры можно вообще написать набор конвертеров на все случаи жизни.
Quote:
Напиши свою библиотеку конверторов.
Quote:
Ты один раз напишешь конвертер и можеш его использовать в десяти местах, а используя входящие параметры можно вообще написать набор конвертеров на все случаи жизни.
ребят, просто ЛОЛ
, вы что издеваетесь. Будет время напишу, что своя библиотека, к тому же, конвертеров это плохо.Quote:
и делай эти конверторы дружелюбными к XAML, чтобы создавать конкретные их экземпляры декларативно
тк объясни что ж вас так притягивает "декларативно" на XAML-е? я там в первом посте спрашивал об этом.
Quote:
Сделай свойство FirstNameInUpper и биндись к нему
да, я вот как раз ехал в метро, и думал над тем, может все "расчеты" надо засовывать в бизнес-объекты. Но пока я не пришол к окончательному выводу, правильно ли это.
Можно сделать класс PersonForGui, который в конструкторе берет исходного Person и выставляет свойства, предназначенные именно для биндинга.
Обернуть таким образом все бизнес-объекты.
Тут могут возникнуть небольшие заморочки с коллекциями.
Вообще, тут бы кодогенерация неплохо пошла, как и для объектов, мапленных на БД и объектов DTO для передачи меж App-доменами. Они часто очень похожие, но все-таки разные
Еще в GUI пользователи <почему-то> не хотят видеть имя колонки в гриде "PersonNameInUpper", а хотят "User name".
http://www.codeproject.com/KB/WPF/wpfdatabinding.aspx
P.S. в конце страничке оказалось, что автор из России
Quote:
Да, меня в БО это засовывать тоже не очень прельщает, но пока ничего лучшего не придумал.Можно сделать класс PersonForGui, который в конструкторе берет исходного Person и выставляет свойства, предназначенные именно для биндинга.Обернуть таким образом все бизнес-объекты.Тут могут возникнуть небольшие заморочки с коллекциями.Вообще, тут бы кодогенерация неплохо пошла, как и для объектов, мапленных на БД и объектов DTO для передачи меж App-доменами. Они часто очень похожие, но все-таки разныеЕще в GUI пользователи <почему-то> не хотят видеть имя колонки в гриде "PersonNameInUpper", а хотят "User name".
похоже на Model-View-ViewModel паттерн, который как раз заточен под WPF binding, насколько я понимаю.
Quote:
Model-View-ViewModel паттерн
да главное придумать название паттерну, и все само сделается
.Статья малоинформативная, суть можно было изложить в двух преложениях:
XAML то вроде у нас для дизайнеров. Кодеры наваяли бизнес-правила в бизнес- объектах
И тут неожиданно выясняется, что прога то не работает, оказывается, что еще что-то надо. А что это что-то? И где его место? Не долго думая вводим еще один уровень. Над названием нам тоже лень думать, поэтому остановимся на комбинации слов ViewModel А уж примеры кода сами напишите...вообще идея простая - для программиста код ГУИ заканчивается на ViewModel, а XAML уже дело техники (с дизайнером или без - не так важно). Главное, связка ViewModel-XAML-GUI получается тонкой, там уже тестировать нечего, декларативное описание databinding лучше всяких юнит тестов (все остальное за тебя в Майкрософт протестировали).