Здравствуйте, Cyberax, Вы писали:
C>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
Затем, что ты пишешь на WPF! Но это так сложно понять, что другой инструмент требует другого подхода и только, начав применять этот подход, ты сможешь ощутить преимущества. Применимо и к .Net и к WPF.
MK>>Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. C>Не, ну хватит мне сказки рассказывать. Надоело уже.
Ну. Ок. Мне тоже надоело.
Здравствуйте, Cyberax, Вы писали:
C>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
Это не со стороны WPF, а со стороны всякого фреймворка, поддерживающего богатые средства байндинга. Вообще, про MVVM я впервые услышал от коллеги, которые программирует на Flex'е.
C>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF
Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей.
C>Не, ну хватит мне сказки рассказывать. Надоело уже.
В свою очередь, просто перестань уже на эти «сказки» отвечать. Продолжай себе программировать в стиле Button1_Click, всё остальное от лукакового, ага.
Здравствуйте, Qbit86, Вы писали:
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF
Q>Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей.
Дело даже не столько в сущностях, сколько в невозможность модульного тестирования юзер интерфейса.
Здравствуйте, MxKazan, Вы писали:
C>>Не, ну хватит мне сказки рассказывать. Надоело уже. MK>Ну. Ок. Мне тоже надоело.
Я завтра сделаю модельный пример того, что мне нужно добиться. Мне интересно, как бы это малыми силами и расширяемо можно было бы сделать на WPF.
Здравствуйте, Qbit86, Вы писали:
C>>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем? Q>Это не со стороны WPF, а со стороны всякого фреймворка, поддерживающего богатые средства байндинга. Вообще, про MVVM я впервые услышал от коллеги, которые программирует на Flex'е.
Я про MVVM услышал от WPFовцев, но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR).
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF Q>Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей.
Не понял что ты этим хочешь сказать. У меня сейчас есть модель данных (исходные данные), есть набор формул (промежуточные результаты вычислений которых могут быть привязаны к графическим элементам) и всё. Даже результат вычислений в явном виде нигде не хранится (а каждый раз при необходимости вычисляется).
У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF.
Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Так как простой декларативный двусторонний байндинг (пусть и с фильтрами и конвертерами) мне не подходит.
C>>Не, ну хватит мне сказки рассказывать. Надоело уже. Q>В свою очередь, просто перестань уже на эти «сказки» отвечать. Продолжай себе программировать в стиле Button1_Click, всё остальное от лукакового, ага.
Я не программирую в стиле Button1_Click — ты меня за дельфиста принимаешь, что ли?
Просто я хочу донести до вас, что стиль WPF не является единственно верным, и иногда приводит к избыточности.
Здравствуйте, Cyberax, Вы писали:
C>Я завтра сделаю модельный пример того, что мне нужно добиться. Мне интересно, как бы это малыми силами и расширяемо можно было бы сделать на WPF.
Только, будь добр, не здесь, а лучше в [dotnet.gui][WPF], ок?
Здравствуйте, Cyberax, Вы писали:
C>Я про MVVM услышал от WPFовцев...
Сам термин придумали WPF'овцы, но разновидность MVVM описывал ещё и Мартин Фаулер — Presentation Model (мне, впрочем, эта статья не нравится). В принципе, паттерн можно использовать практически в любом GUI фреймворке, но если он не поддерживает привязок, то получится слишком много рутинного boilerplate кода. В своей статье Мартин с этой мыслью солидарен:
Probably the most annoying part of Presentation Model is the synchronization between Presentation Model and view. It's simple code to write, but I always like to minimize this kind of boring repetitive code. Ideally some kind of framework could handle this, which I'm hoping will happen some day with technologies like .NET's data binding.
C>но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR).
Но ты ведь отдаёшь себе отчёт в том, что буквально каждая твоя реплика выдаёт в тебе верхоглядство и дилетантизм? Серьёзно, не обижайся. Нет ничего плохого в незнании какой-то области, неприятно лишь явное пускание пыли в глаза. Хорошо хоть, что эта ветка подтолкнула тебя (судя по всему) на лету осваивать матчасть.
C>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF.
А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов.
C>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI.
Возможно, для этого и есть модель представления (не путать с моделью данных).
C>Просто я хочу донести до вас, что стиль WPF не является единственно верным, и иногда приводит к избыточности.
Если честно, по-моему здесь никто особо и не обеспокоен «единственно верностью» WPF'а. Более того, у меня даже есть предположение, что байндинги в том же Flex'е мощнее и удобнее таковых в WPF.
Здравствуйте, Qbit86, Вы писали:
C>>Я про MVVM услышал от WPFовцев... Q>Сам термин придумали WPF'овцы, но разновидность MVVM описывал ещё и Мартин Фаулер — Presentation Model (мне, впрочем, эта статья не нравится). В принципе, паттерн можно использовать практически в любом GUI фреймворке, но если он не поддерживает привязок, то получится слишком много рутинного boilerplate кода.
Если покопаться, то тут можно до Smalltalk'а дойти, где тоже подобный паттерн широко использовался. Там и байндинг был очень прозрачный — язык-то динамический, с поддержкой интроспекции.
C>>но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR). Q>Но ты ведь отдаёшь себе отчёт в том, что буквально каждая твоя реплика выдаёт в тебе верхоглядство и дилетантизм?
А может просто тебе так кажется?
Q>Серьёзно, не обижайся. Нет ничего плохого в незнании какой-то области, неприятно лишь явное пускание пыли в глаза. Хорошо хоть, что эта ветка подтолкнула тебя (судя по всему) на лету осваивать матчасть.
Я вообще-то матчасть знаю, просто смотрю на неё с другой точки зрения. Мне многое в WPF просто неинтересно — типа анимирования всех свойств или добавления контролов на грани вращающегося кубика.
C>>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF. Q>А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов.
В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход.
C>>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Q>Возможно, для этого и есть модель представления (не путать с моделью данных).
И вот мне её не хочется делать.
Здравствуйте, Cyberax, Вы писали:
C>>>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем? Q>>Это не со стороны WPF, а со стороны всякого фреймворка, поддерживающего богатые средства байндинга. Вообще, про MVVM я впервые услышал от коллеги, которые программирует на Flex'е. C>Я про MVVM услышал от WPFовцев, но использовал её ещё раньше в JFace (система байндинга для SWT), году так в 2003 (AFAIR).
C>>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF Q>>Этот «лишний слой» как раз является идиоматическим примером разрыва связей (твоих «циклических зависимостей»). Вместо горизонтальной зависимости мы вводим общую сущность, и вертикальные зависимости. Преимущество налицо: если у тебя было n сущностей на одном уровне, то всевозможных связей у тебя n(n−1)/2 (нарисуй полный граф и посчитай число рёбер); вводя дополнительную сущность на верхний уровень, ты устанавливаешь связи только с ней, всего n связей. C>Не понял что ты этим хочешь сказать. У меня сейчас есть модель данных (исходные данные), есть набор формул (промежуточные результаты вычислений которых могут быть привязаны к графическим элементам) и всё. Даже результат вычислений в явном виде нигде не хранится (а каждый раз при необходимости вычисляется).
C>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF.
Открой для себя INotifyPropertyChanged.
C>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Так как простой декларативный двусторонний байндинг (пусть и с фильтрами и конвертерами) мне не подходит.
Ты сам-то хоть знаешь почему он тебе не подходит? Уверен, что нет...
Цирк.
Q>>В свою очередь, просто перестань уже на эти «сказки» отвечать. Продолжай себе программировать в стиле Button1_Click, всё остальное от лукакового, ага. C>Я не программирую в стиле Button1_Click — ты меня за дельфиста принимаешь, что ли?
C>Просто я хочу донести до вас, что стиль WPF не является единственно верным, и иногда приводит к избыточности.
Здравствуйте, Cyberax, Вы писали:
C>>>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF. Q>>А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов. C>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход.
Нет слов... Ты все еще не допер, что контролы в WPF привязываются не к данным, а к контроллеру.
Здравствуйте, kuj, Вы писали:
Q>>Более того, у меня даже есть предположение, что байндинги в том же Flex'е мощнее и удобнее таковых в WPF.
kuj>Расскажи подробнее здесь http://rsdn.ru/forum/message/3325376.flat.aspx
Ничем не могу помочь, сам с радостью послушал бы. Один знакомый, ко мнению которого прислушиваюсь, вкратце рассказывал о кое-каких фишках Flex'а. В частности, если я правильно понял, в объявлении привязки можно указывать выражение над привязываемым полем — ну там домножить на что-нибудь, записать результат вызова функции над источником, etc. В WPF же, даже если надо взять просто отрицание какого-нибудь булевского поля, приходится городить конвертор.
На всякий случай повторю, вышеизложенное недостоверно, с чужих слов, требует более глубокого ознакомления с предметом. Кстати, надо подписать упомянутого коллегу изложить мысли по поводу Flex'а в ту ветку.
Здравствуйте, Qbit86, Вы писали:
Q>Ничем не могу помочь, сам с радостью послушал бы. Один знакомый, ко мнению которого прислушиваюсь, вкратце рассказывал о кое-каких фишках Flex'а. В частности, если я правильно понял, в объявлении привязки можно указывать выражение над привязываемым полем — ну там домножить на что-нибудь, записать результат вызова функции над источником, etc.
А можно спросить отсюда более подробно? В частности, мне было бы это очень интересно.
Здравствуйте, gandjustas, Вы писали:
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. G>Так может вы еще и MVC и MVP не применяете? тоже обходитесь "другиси способами"? G>Надеюсь эти способы не сводятся к запихиванию всего в OnClick?
Нет.
G>Можете выслать.
Готовлю...
G> OnPropertyChanging("Money"); G> OnPropertyChanging("MoneyPercent");
Сломается.
G> _money = Math.Round(value * MaxMoney / 100, 1); G> OnPropertyChanged("Money"); G> OnPropertyChanged("MoneyPercent");
Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага.
(мелочи типа неправильного поведения Math.Round опускаю).
Ну и у меня всё это уложится примерно в 5 строк прикладного кода
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
M>Как по мне, по многим параметрам C# (да и Java тоже) занимает промежуточное положение,
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. G>>Так может вы еще и MVC и MVP не применяете? тоже обходитесь "другиси способами"? G>>Надеюсь эти способы не сводятся к запихиванию всего в OnClick? C>Нет.
G>>Можете выслать. C>Готовлю...
G>> OnPropertyChanging("Money"); G>> OnPropertyChanging("MoneyPercent"); C>Сломается.
Как сломается?
G>> _money = Math.Round(value * MaxMoney / 100, 1); G>> OnPropertyChanged("Money"); G>> OnPropertyChanged("MoneyPercent"); C>Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага.
Какого инкремента?
Там текстбоксы.
C>Ну и у меня всё это уложится примерно в 5 строк прикладного кода
Ага, и 180 кб фреймворка.
Здравствуйте, Cyberax, Вы писали:
C>>>У меня это всё сделано с помощью моей системы байндинга, которая работает на push-идеологии (т.е. байндинг изменяет свойства контролов), которая противоположна идеологии WPF. Q>>А можешь подробнее, с конкретикой? В WPF байндинг тоже изменяет свойства контролов. C>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход.
И как при таком подходе тестировать логику UI?
C>>>Если делать по WPF'у, то мне нужно будет где-то хранить промежуточные данные и как-то подвязывать вычисления изменений к GUI. Q>>Возможно, для этого и есть модель представления (не путать с моделью данных). C>И вот мне её не хочется делать.
И для этого надо говродить немалый фреймвок.
Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие.
Здравствуйте, gandjustas, Вы писали:
C>>В WPF ты привязываешь контролы (которые могут быть даже неименованы) к данным модели. Я делаю наоборот — привязываю данные (возможно неименованых) формул к именованым контролам. Противоположный подход. G>И как при таком подходе тестировать логику UI?
А накой её тестировать? GUI должны тестировать живые люди.
Автоматически тестировать надо формулы, чему моя система только способствует.
C>>И вот мне её не хочется делать. G>И для этого надо говродить немалый фреймвок. G>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие.
Мои проблемы не решаются простыми способами...
Здравствуйте, gandjustas, Вы писали:
G>>> OnPropertyChanging("Money"); G>>> OnPropertyChanging("MoneyPercent"); C>>Сломается. G>Как сломается?
Лень объяснять.
C>>Сломается, если шаг инкремента поля ввода процентов (спиннера) будет меньше минимального шага. G>Какого инкремента? G>Там текстбоксы.
Ну попробуй для спиннера сделать.
C>>Ну и у меня всё это уложится примерно в 5 строк прикладного кода G>Ага, и 180 кб фреймворка.
У меня таких полей около 5 тысяч штук. Будем считать экономию?
Здравствуйте, gandjustas, Вы писали:
G>Изобретение веосипедов за деньги заказчика в наше время не самое хорошее занятие.
Заметь, что при этом эти же джависты рассказывают нам басни о том, что под джава больше библиотек и что это дотнетчики изобретают велосипеды, либо копируют их из джава.
