В принципе может, но этот шаблон - некая адаптация MVC к возможностям WPF. Так что при наличии отсутствия такой мощной системы привязок ее видимо придется в том или ином виде реализовывать самому и выгода от такого подхода видимо будет сомнительной.

Ну во-перых, в данном контексте не очень понятно, чем можно руководствоваться, набирая символ из другого алфавита, вроде как негде переключать язык ввода. Во-вторых, если ты заметил, то эта часть вьюмодели представляет из себя прокси-класс для класса модели и все эти свойства можно сгенерировать, по крайней мере я бы так и сделал, особенно если учесть, что таких классов будет много и свойств у них побольше и заниматься ручным набором повторяющегося кода смысла нет.

Контроллер обеспечивает связь с контроллером?  С моделью ты хотел сказать? Так собственно да, модель представляет данные, логика в контроллере и связь между моделью и представлением ложится на контроллер. В MVVM в свою очередь за счет системы привязок и команд сложная логика не требуется, поэтому вьюмодель просто адаптирует модель к возможностям представления. В приведенном примере это уведомление заинтересованных сторон об изменении значений свойств и команды.

Ты точно не путаешь контрол с контроллером?

А кто говорил о революционности? Здесь скорее эволюция MVC. Можно считать этот шаблон его разновидностью.

Программного кода. Все таки структурный код и программный - разные вещи. Да и вообще там выше речь шла не о том, что без единой строчки кода, а о том, что в классе окна можно вообще без кода обойтись, в том числе без обработчиков событий. Да и XAML частично в дизайнере строится.

Это не данные, а структурный код. Что можно проверить - проверяется и подсказки в редакторе выдаются, но если не известно каким будет контекст данных и есть ли в соответствующие поля, то этого не проверишь, хотя и ошибки это не вызовет, просто пустая привязка ничего не выдаст.

Я уже Злохе по этому поводу отвечал, что переход на другую технологию скорее даже проблемы вызовет. Речь ведь не идет только о тебе конкретно. Если твои задачи не требуют функционала впф и при этом ты их успешно решаешь на  дельфах, а впф еще изучить надо, то переход скорее будет бессмысленным.

Так это и так понятно, но я думаю, что не было смысла раздувать тему на 60 с лишним страниц, обсуждая сугубо твои предпочтения. Мы ведь пытаемся выяснить что лучше и (надеюсь) стараемся вынести максимально объективную оценку.

Ты видимо ждешь, что я спорить начну? Но на самом деле ты довольно точно сформулировал проблему. Гуй достаточно трудно тестировать и модульные тесты для этого не заточены. И это как раз и есть одна важнейших причин того, что хорошая архитектура требует максимально отделять логику от представления. И если этого правила придерживаться, то тесты еще и как можно будет применять.

Честно говоря, я вообще не в курсе, что это за проблема с переключением окон. Дельфу 2005 я помню, она первый фреймворк поддерживала, студия 2003 была заточена под него же, но она просто летала по сравнению с той дельфой. Кстати первый фреймворк давно в историю ушел, а впф вообще в третьем появилась

А с призмой есть подобные проблемы? Там иде на основе VS Shell сделана.

И винда и sql server и многое из того, что ты пользуешь в дельфах, - тоже майкрософт, может пора на линь переходить?

Ну лично я никого ни за что не агитирую, так что... А в целом товарищ все правильно написал, очевидность преимуществ впф возрастает по мере увеличения сложности программы, да и не только впф, а  вообще архитектурно-ориентированных платформ.

А как еще показать, что получилось? Не хочешь читать - вставь код в свой проект и посмотри. Это как раз отличный способ текстом передать структуру окна.
А чем это лучше... ну попробуй сложный интерфейс написать в коде, а потом разобраться где там что, если что не туда притулишь. Об этом уже говорили вроде.


Если то, что я вижу в гуевых ява-приложениях - и есть JavaFX, то чем она лучше свинга?

Этому должно быть объяснение. Первое, что приходит в голову - отсутствие вменяемых средств разработки гуя или платформы гуестроительства или и того и другого.

Из того, что ты тут писал, я понял, что ты не заморачиваешься по части отделения логики от представления. 

На предмет чего писькомерялку производить хочешь? UI предлагаю реализовать на гранях трехмерного куба, который будет вращаться мышкой  

Та какая там занятость, зассали все 

Эмммм... если брать тот пример из блога, то там такого кода практически нет. Если использовать доступный в студии инструментарий, то классы модели в несколько кликов можно сгенерить из базы данных, а вьюмодель можно  получить написав собственный небольшой генератор или отредактировав тот, который генерит модель. Там это делается с помощью текстовых шаблонов, штуковина доступна в студии, синтаксис прост и делается это один раз и генерит сколько угодно классов. Код команд тоже стандартный, то, что там написано можно в две строки уместить, а так вообще можно сделать шаблон кода и если бы там эта функция использовалась то, все, что пришлось бы написать руками уложилось бы в три строки такого содержания

Count++;
Count--;
Return Count > 0;

Сложность оценивай сам. Что касается чего-то относительно полноценного, то как бы объяснили уже, что чем больше проект, тем больше ощущаются преимущества, тогда уж пишите что-то большое 

Потом расскажете у кого длиннее 

Не ты один такой. Проблема линукса именно в том, что найти под него нужный софт - проблема, а то, что предлагается взамен - не устраивает. И проблема эта неразрешима, поскольку никому не хочется писать коммерческий софт под платформу, на которой сидят те, кто за софт платить не любит

Да, хотел сказать с моделью.

Но прикладная логика реализуется моделью.
Т.е, в данном случае, решать можно ли списать остаток по позиции должна модель а не MV.
Ведь согласись, с одной моделью может работать несколько вью, контроллеров, или всяких там MV, и эта логика должна быть реализована единообразно.


А ниже была фраза


Меня берут страшные сомнения, что в этой стране под виндой сидят преимущественно те, кто за нее заплатил или же готов заплатить. В корпоративном секторе, может быть и да, в домашнем же обиходе, если и сидят на лицензии, то на ОЕМ. За OEM же лицензию оплата взымается неявно.

Коммерческий же софт под эту платформу, полагаю, не пишут по той причине, что ее доля слишком мала на рынке, а не потому, что ее предпочитают халявщики. А мала, в свою очередь, в том числе и потому что коммерческого софта мало пишут. Замкнутый круг ((

В том же, что найти нужный софт проблема - не факт. Все что мне нужно было для домашнего использования, мной было найдено. Не сразу, не быстро, пришлось поперебирать много чего, но таки было. Если бы я встал перед необходимостью заплатить 10к за венду с офесом, я бы отказался от своей любимой игрушки в пользу другой, похожей, но не любимой, которая под линь идет  

Добавлено через 11 минут и 48 секунд

Проблема символа "C/C" это гипербализированный случай, который не палится глазами, при том, что символы находятся на одной кнопке. Ты мог писать коментарий, потом увидеть, что у тебя стоит "c", исправить ее на "С" и ничего подозрительного не заметить. С символами "a" и "а" все намного проще хотя бы потому, что набрав "ф" вместо "a" ты имеешь шанс исправиться сразу.

Ну а так вобще представление программных структур литералами, это как позднее связываении, как динамическая типизация/вызовы и вся прочая хрень, которая требует покрытия юнит тестами, отвлекая тем самым от покрывания тестами действительно нужного функционала. :inknw

Да, но

Но факт остается фактом: при всей бесплатности, гибкости и прочих достоинствах линукса его доля в десктопе, на сколько я знаю, где-то около 1%. Почему под нет приличного софта? А то, что в этой стране, да еще и дома, так это не главный источник дохода. Ну это просто мнение в конце концов, может у тебя есть другое объяснение ситуации, тогда поделись.

Если бы софт был, то причин не сменить платформу я вообще не вижу. В конце концов ось нужна только для того, чтобы запускать на ней софт.

Уж игрушку-то, вообще не понимаю какая разница в какую играть: что одна - г-но, что другая   

 Не надо ля-ля: http://stopgame.ru/newsdata/10699 Виндузятники поколениями привыкли тырить. 
Как всегда выводы не правильные. Это то же самое почему якобы под java мало гуя и мало либ гуйных. Всё есть, на самый разный вкус - просто проходит мимо. http://java-sources.net/open-source/swing
JBuilder вон с визуальным редактором тихо помер.
Конечно много неопределённости, но где она есть? У них цель - сделать универсальную либу. Сейчас они вроде оперделились на javaFX 2 переходят, причём 1 версию гады кинули (мб и к лучшему). Она от swing-awt не зависит. Ну и SWT - тоже неплохая.

Ну это не общая тенденция, просто в данном случае это небольшое отступление от правил ради серьезного сокращения количества кода. Можно было бы запросить  имя свойства через рефлексию, но как мне кажется, это из пушки по воробьям. Помнится ты как-то сильно активно меня убеждал, что джинерики нафиг никому не нужны, но они устраняют гораздо большие проблемы того же плана, о котором ты сейчас пишешь и тебя это как-то не смущало, а тут прямо вывернуло.

Я не знаю, как там в жабе, или питоне, но в дельфине строковый тип абсолютно безопасен ровно до того момента, пока ты не лезешь в его внутреннюю структуру. Например, в бинарный файл записать, а для этого надо как-то перевести строку в байтовый буфер. Но и тут уже есть все готовенькое. Можно вообще ничего про устройство не знать и про хитрости экономии памяти через счетчик ссылок.
Максимум где-то может производительность подсесть, если, например, const при передаче строки забудешь, хотя любой программер при передаче сложных данных должен сразу подумать, а не передать ли мне вмето массивчега, или структурки ссылочку на них.



Ну а какие есть?



Э-э... Ну я в алголоподобных языках 2 типа объектов знаю. Те, которые ссылочные классы и те, которые не ссылочные, как старый object из Паскаля, который Delphi тоже поддерживается и юзается в KOL. При работе классы в принципе удобнее, т. к. они обычно создаются и уничтожаются, могут копироваться ссылки на них, но сами данные классов копируются крайне редко. Кстати, никаких конструкторов копирования в Delphi нет, есть метод Assign у TPersistent, прямого наследника TObject, т. е. все реализовано не операторами, а через библиотеку, через нее же и инстанцинация экземпляров. Никто не мешает переопределить при необходимости.
Для мелочевки же всегда есть нессылочные структуры, которые уже почти лет 10, как имеют свои методы.



А почему на Си не получилось, а на Паскале получилось? Да и довольно много людей, роль которых в истории IT повыше, чем у Васи Пупкина с параллельного потока будет, весьма критично высказывались о плюсах. О современном Паскале же никто ничего плохого не говорит, вполне себе продуманный язык. Характерно, что как язык обучения ни Си, ни плюсы не состоялись, тут я вообще настроен так, что никаких отдельных языков для обучения делать не надо, студент должен изучать практический инструмент. Сложный в обучении инструмент будет точно так же сложен в работе.

Меня игры как-то мало волнуют(если ты это имел в виду, поскольку я не уверен, что понял твою мысль, изложенную в виде ссылки).

Не понял. При чем тут виндузятники? Столько эмоций в ответ на мое замечание следовало бы сопроводить достоверной статистикой относительно победоносного шествия линукса по десктопу или рациональное объяснение того, почему этого шествия не происходит.

Ты всегда мои выводы отслеживаешь? Неужели ни одного правильного не обнаружил?

Я понятия не имею сколько там либ. Я не видел приличного гуя, написанного на яве и в принципе не понимаю, почему джависты так не любят гуй-приложений, если у них все есть, а те, которые любят, почему-то не используют то изобилие архизачетных либ. 

В доднете например. Что назвала перспективным генеральная линия партии, по тому книжки и читать. Пиар технологии, донесение до масс, возьмет на себя папка. Если прочитаешь толстую книшку с логотипом папки и бахнешь пару поделок, которые ты впишешь в резюме, будь спок, ты уже в мейнстриме.

В жаве же менстримы трудно определены, потому как конец никто в твердой руке не держит, мейнстрим хлещет куда не попадя, чтобы оказаться в нем - надо либо очень уж много книжек прочесть, либо просто быть великим лакером.

Добавлено через 5 минут и 57 секунд

я не совсем понял что они прям устраняют. Я так понимаю они предоставляют возможность в чуть более компактной форме реализовать тот же функционал, который можно было бы реализовать наследованием от базовых классов. 

Это сообщение отредактировал(а) Zloxa - 22.4.2013, 13:20

Как насчет типизированных коллекций? Как ты без джинериков работаешь с коллекциями пользовательских типов?

Нет, обычно ты видишь Swing или SWT.


Они мало кому нужны, т.к. несмотря на кроссплатформенность, джава -- это в первую очередь *никсы, т.е. в 99% случаев серверы без гуя. А уж в те времена, когда на десктопах джава сильно тормозила, конкурировать с Делфи и ВБ было проблематично.

Создаю класс-коллекуию, наследуя его от базового типа-коллекции of object.

Нет, они нужны. Другой вопрос, что тот инструментарий, которым располагает ява, не позволяет ей быть конкурентоспособной на рынке приложений такого типа. Так что давай все-таки называть вещи своими именами.

Добавлено через 2 минуты и 45 секунд

Для каждого случая, когда это надо?  Ну, если всякий раз, когда можно использовать джинерики, ты пишешь отдельную реализацию для каждого типа, то конечно. Но это мазохизм вообще-то.

diadiavova, ладно, прошу прощения, если слово "виндузятники" задело, сам вынужден пользоваться.. 
Немного защищу всех, однако часто мы слишком закапываемся в окружающую действительность и не хотим видим ничего вокруг.

Да она как бы и на серверах не шибко высокую производительность показывает.

По кр. мере оракл от версии к версии переписывает функционал ранее реалзиованный на жаве на С, при этом на порядки увеличивая производительность. Взять к примеру пакет DBMS_XMLSTORE, введенный в десятке. Основная фича его в том, что он почти то же самое, что введенный в прошлой версии DBMS_XMLSAVE, но переписанный с жавы на С. Правда с потерей части функционала, потому пакет не заменен, а введен новый. Наверное не ошибусь, заявив, что начиная с 9й версии, где они на С переписали большУю часть пакетов работы с XML, в каждой новой версии появляется что-то, переписанное ораклом с жавы на С. 

Добавлено @ 13:54

Всамделе не так уж и часто надо, не так уж и много надо, да и там совсем ничего получается строчек кода 
Конечно генериками лаконичненько получается.

Это сообщение отредактировал(а) Zloxa - 22.4.2013, 13:57