Здравствуйте, Cyberax, Вы писали:
C>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов?
Если воспринимать Binding как тупую трансляцию свойств, то, конечно, нафиг оно не нужно. Только Binding в WPF — это не просто пересылка значения. Это еще и отслеживание изменений, это преобразование типов, это фильтрация, это сортировка, это в конце концов декларативное выражение связей, которое гораздо читабельнее (впрочем я давно заметил, что последнее совсем не аргумент, ага). Посмотрел бы я, как ты программно обеспечишь привязку между контролами разных уровней визуального дерева в ситуации, когда содержимое этого дерева постоянно меняется. Там прилично нюансов и заботится о них нет никакого желания.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали: G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить. C>PS: вообще поражают меня сторонники ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ}, думающие, что она решает все проблемы. Маловато нестандартных задач, видимо, решают...
А меня поражают сторонники, что одна крайность лучше другой. Тупое нежелание осваивать ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ} ничем не лучше. И очень забавляет, как эта "директива" действует на некоторых голосовальщиков
Здравствуйте, Cyberax, Вы писали:
C>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами.
А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода. Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. А ты лишний слой... Это как торт из печенки! Можно сделать слоями и всё будет вкусно, а можно накидать превратить всё это в кашу и потушить — тоже есть можно, но уже не то...
Здравствуйте, MxKazan, Вы писали:
C>>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. MK>А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода. Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM. А ты лишний слой... Это как торт из печенки! Можно сделать слоями и всё будет вкусно, а можно накидать превратить всё это в кашу и потушить — тоже есть можно, но уже не то...
Просто Cyberax не слышал ни о single responsibility principle, ни о separation of concepts, ни о testability.
Здравствуйте, kuj, Вы писали:
C>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. kuj>Я ржал... Ты либо туп либо притворяешься. Тебя уже десять раз ткнули носом, разжевали и положили в клюв, дали мультик посмотреть, а ты все еще не допер как работает MVVM и зачем вообще придумали MVC? Ндааааааааа.....
Тебе, куй, вообще говорить что-то бесполезно. Кроме себя ты никого больше не слышишь. Примерно как Шеридан.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kuj, Вы писали:
C>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. kuj>>Я ржал... Ты либо туп либо притворяешься. Тебя уже десять раз ткнули носом, разжевали и положили в клюв, дали мультик посмотреть, а ты все еще не допер как работает MVVM и зачем вообще придумали MVC? Ндааааааааа..... C>Тебе, куй, вообще говорить что-то бесполезно. Кроме себя ты никого больше не слышишь. Примерно как Шеридан.
Бугага, ты то все слышишь. Когда тебе десять человек одно и то же твердят, а ты продолжаешь свое "ла-ла-ла".
Вытащи бревно из своего глаза прежде, чем указывать на сучок в чужом, умник.
kuj>>Просто Cyberax не слышал ни о single responsibility principle, ни о separation of concepts, ни о testability.
AV>Точно? Я с ним водку за одним столом не пил и не работал с ним тоже, но у меня сложилось совсем обратное впечатление.
Зашибись. Впечатление теперь складывается исключительно после распития поллитры.
Лезь обратно под то бревно, из-под которого вылез.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить.
C>PS: вообще поражают меня сторонники ${ПОСЛЕДНЯЯ_ТЕХНОЛОГИЯ}, думающие, что она решает все проблемы. Маловато нестандартных задач, видимо, решают...
Так вас просили привести пример нестандартной задачи, а вы привели пример который в WPF решается стандартным (де-факто) подходом.
А если вы придумываете нестандартные решения для стандартных задач, то не стоит этим так бравировать, это вам чести не сделает.
ЗЫ. Кто-то сказал что у любой программистской задачи есть два решения: "правильно" и "по-своему" вы видимо выбрали второй путь.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
Как по мне, по многим параметрам C# (да и Java тоже) занимает промежуточное положение, что делает их более-менее пригодным для решения большого круга задач. Но очень часто для конкретной задачи удобнее и предпочтительнее был бы язык со специальными возможностями. Но именно эта универсальность и не даст загнуться языкам C# и Java.
Здравствуйте, Mystic, Вы писали:
KV>>1. Он слишком низкоуровневый. Почти такой же низкоуровневый для IL, каким является Си (без плюсов) для ассемблера. Есть мнение, что многим разработчикам, такая низкоуровневость только вредит.
M>Как по мне, по многим параметрам C# (да и Java тоже) занимает промежуточное положение, что делает их более-менее пригодным для решения большого круга задач. Но очень часто для конкретной задачи удобнее и предпочтительнее был бы язык со специальными возможностями. Но именно эта универсальность и не даст загнуться языкам C# и Java.
kuj>>>Просто Cyberax не слышал ни о single responsibility principle, ни о separation of concepts, ни о testability.
AV>>Точно? Я с ним водку за одним столом не пил и не работал с ним тоже, но у меня сложилось совсем обратное впечатление.
kuj>Зашибись. Впечатление теперь складывается исключительно после распития поллитры.
Зашибись, читаем только то, что хочется. Вторую половину (про работу) уже, видать, не осилил.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. G>>Это "счастье" называет MVVM, вы считаете такой подход ненужным? C>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами.
Так может вы еще и MVC и MVP не применяете? тоже обходитесь "другиси способами"?
Надеюсь эти способы не сводятся к запихиванию всего в OnClick?
G>>>>Вот приведите код, который показывает что нет особой разницы. Вот как раз с вашими процентами. C>>>Великоват он... Это у меня уже почти целый фреймворк. Я могу привести пример как оно выглядит в прикладном коде. G>> G>>Давайте весь код, уж очень интересно во сколько раз удастся его сократить. C>Весь код я всё равно не дам. Его там сейчас 180 килобайт, не считая библиотек. Пример вечером могу прислать.
Можете выслать.
Я тут написал небольшой пример с вашими процентами, получилось значительно меньше 180 кб.
Здравствуйте, MxKazan, Вы писали:
C>>Я не считаю нужным создание лишнего слоя только для того, чтобы ощутить всю крутость байндинга в WPF, если можно обойтись другими способами. MK>А че бы тогда вообще не перестать использовать ООП. Пиши всё на голом C, на фиг тебе лишнии слои? Ну право, несмешно ведь уже. Ясно видно, что ты не пробовал изменить взгляд на вещи и начать разрабатывать интерфейс приложения по другому: когда логика в одном классе, представление в другом (хотя вроде ссылался на что-то подобное). Только, разрабатывая нечто подобное, можно понять все плюсы этого подхода.
У Anatolix'а есть замечательная подпись: "Любая проблема решается введением дополнительного уровня абстракции, кроме слищком большого числа уровней абстракции". Я не против добавлять лишние слои там, где это надо.
Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
MK>Да хотя-бы то, что бизнес-логика практически перестает быть связанной с такой вещью как события контролов, что клиентские бизнес-задачи решаются одним классом, который понятия не имеет "как это нарисуется" — только за это уже стоит взятся за MVVM.
Не, ну хватит мне сказки рассказывать. Надоело уже.
Здравствуйте, User239, Вы писали:
C>>Внимание, вопрос: а нафиг мне нужен тогда байндинг, если он вырождается в 1-1 привязку к свойствам специальных синтетических объектов? U>Ну так байндинг для того и нужен, чтобы отделить вашу логику от представления.
Нет. Бйндинг нужен чтобы связать представление и данные. Какие именно данные — это вопрос. Иногда можно сразу реальные данные модели приложения использовать.
С>>Так что с WPF или аналогичными механизмами — нужно делать промежуточный слой визуальных моделей. Мне вот это счастье нафиг не нужно. U>Конечно код для "чёткого механизма ветирования и отката изменений до вычисленного корректного состояния" за вас не напишет ни один фреймворк на свете. Вопрос лишь в том, где писать этот код. Если это не "промежуточный слой визуальных моделей", тогда что? Обработчики кнопок (образно)? В этом случае код явно будет больше, чем при байндинге (чего стоят одни getText, setText). Не говоря уж о том, насколько увеличится подверженность различным ошибкам.
У меня другой результат — мне проще было всё написать с классическими getText()/setText(), чем использовать более сложные механизмы. Как раз из-за того, что при этом от GUI-фреймворка получается меньше самодеятельности там, где она не нужна.
Простой пример: у меня есть элементы ввода A, B, C, D, где C=A+B, а D=сложное_вычисление(C). Мне в модели нафиг не нужно отдельное поле для C — но мне его придётся сделать, если я захочу использовать байндинг. Так как привязаться к значению формулы нормально с помощью стандартного механизма не получится (почему так, я уже писал).
Именно поэтому я всегда выбираю фреймворки, которые позволяют удобно при необходимости падать на самый низкий уровень.
Здравствуйте, Cyberax, Вы писали:
C>Но только чтоб оно было идеологически правильно со стороны WPF? Зачем?
Иди ртфмь http://ru.wikipedia.org/wiki/Model-View-Controller
и не задавай больше глупых вопросов.
C>Простой пример: у меня есть элементы ввода A, B, C, D, где C=A+B, а D=сложное_вычисление(C). Мне в модели нафиг не нужно отдельное поле для C — но мне его придётся сделать, если я захочу использовать байндинг. Так как привязаться к значению формулы нормально с помощью стандартного механизма не получится (почему так, я уже писал).
Афигеть, дайте два! А теперь расскажи нам как ты будешь писать юнит тесты. Слушаем.