Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, Codechanger, Вы писали:
C>>Примеры в студию. Будем, так сказать, отталкиваться от реальности.
RT>тут
Здравствуйте, RadmirT, Вы писали:
RT>Так я ни не говорю что WPF плох. Я просто пытаюсь донести что ненадо разимахивая флагом все проекты делать на WPF. Есть целая куча задач, решение которых на WinForms проше и эффективнее чем решение аналогичной задачи на WPF.
Насчет проще — всё не так однозначно. Скажем, с текстом будет удобнее работать в WPF. Задавать шаблоны для ячеек тоже будет удобнее в WPF. Сама отрисовка сетки, возможно, проще да, но только до тех пор, пока визуальщина примитивна. Еще раз уточню, что я это написал о простоте, а не об эффективности.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, RadmirT, Вы писали:
MM>Насчет проще — всё не так однозначно. Скажем, с текстом будет удобнее работать в WPF. Задавать шаблоны для ячеек тоже будет удобнее в WPF. Сама отрисовка сетки, возможно, проще да, но только до тех пор, пока визуальщина примитивна. Еще раз уточню, что я это написал о простоте, а не об эффективности.
Абсольтно соглаен. Когда начинали проект именно эти веши склоняли нас к выбору WPF. Но к сожалению критерий "скорость" перевесила все аргументы за.
Здравствуйте, RadmirT, Вы писали:
RT>Я говорю что в конкретном случае, когда необходимо оперироват большим количеством примитивов,которые постоянно удаляются/добавляются, использования WinForms + GDI+ эффективнее чем WPF + DirectX
Поддерживаю. По логике вещей именно так и должно быть. Ведь чудес не бывает. Сейчас сам озадачен, стоит ли переводить свой редактор диаграмм из WinForms на WPF. Если отталкиваться от того, что элементов на диаграмме будет не так много, то можно и перевести. Но сейчас особый предмет моей гордости — это способность диаграммера сносно держать в динамически обновляемом состоянии более ста тысяч элементов одновременно на довольно стареньком пятилетнем ноутбуке с целероном и очень скромной интегрированной видеокартой. Отдаю себе отчет, что при переходе на WPF и Silverlight такая [не очень-то и нужная] способность пропадет, как пить дать.
Re[7]: Будущее WPF?
От:
Аноним
Дата:
08.09.10 09:42
Оценка:
G>>>Тогда делай как предполагалось, возможностей уйма. B>>Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него. G>Для динамический генерации UI уже есть фреймворк, называется он Binding+ContentPresenter+DataTemplate. Ты просто формируешь метаданные для этого дела и все.
Здравствуйте, Аноним, Вы писали:
G>>>>Тогда делай как предполагалось, возможностей уйма. B>>>Специфика разработки иная. Не 100 человек — 100 форм. а меньшее количество — 1 фреймворк — 10 проектов на базе него. G>>Для динамический генерации UI уже есть фреймворк, называется он Binding+ContentPresenter+DataTemplate. Ты просто формируешь метаданные для этого дела и все.
А>а можно подробней описать процесс?
Здравствуйте, RadmirT, Вы писали:
RT>По поводу скорости работы я с тобой не согласен. RT>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
WPF — это не графика, это другой подход к построению пользовательского интерфейса (Data Driven UI). Для рисования у вас есть GDI, GDI+, Direct2D, DirectX. WPF использует DirectX, а не пытается его собой заместить.
Здравствуйте, MozgC, Вы писали:
MC>Ваши мысли? Приживется? Будет ли мейнстримом? Глянул вакансии — на данный момент не сильно востребован. Вот интересно как будет в будущем.
Технология отличается чрезвычайной гибкостью, но при этом весьма высоким порогом вхождения. Те у кого хватит способностей справиться с порогом вхождения будут её использовать безусловно. Справится ли с этим в целом индустрия — вопрос интересный. Скорее всего компании, занимающиеся UI компонентами, наклепают компонентов попроще и подоступнее в использовании и будет всем счастье.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, MozgC, Вы писали:
MC>Глянул вакансии — на данный момент не сильно востребован.
Я тоже глянул на дайсе. Для WPF в два раза больше вакансий, чем для винформс.
Здравствуйте, olegkr, Вы писали:
MC>>Глянул вакансии — на данный момент не сильно востребован. O>Я тоже глянул на дайсе. Для WPF в два раза больше вакансий, чем для винформс.
Я тоже глядел как раз на дайсе по запросу ".NET + C#" и вручную просматривал тексты вакансий. Просмотрел 60-80 вакансий — по WinForms чуть-чуть больше чем по WPF.
Здравствуйте, MozgC, Вы писали:
MC>Я тоже глядел как раз на дайсе по запросу ".NET + C#" и вручную просматривал тексты вакансий. Просмотрел 60-80 вакансий — по WinForms чуть-чуть больше чем по WPF.
Не надо гадать на пальцах wpf — 724 results winforms — 410 results
Факт заключается в том, что винформс весьма активно заменяется wpf
Здравствуйте, belnetmon, Вы писали:
B>Здравствуйте, MxMsk, Вы писали:
MM>>Давай мериться: кидай сюда код TreeView, в элементы которого, скажем, встроен ComboBox. У нас в проекте есть такая реальная задача. Давай, покажи код на Windows Forms, который это реализует.
B>Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
Вот обычный ListBox с кастомным ItemTemplate. Биндится на List<T> из итемов. Правда это Silverlight 4, а не WPF, но не суть.
Давай такое же на WinForms. Всё очень просто по сравнению с WinForms.
Здравствуйте, belnetmon, Вы писали:
B>Здравствуйте, MxMsk, Вы писали:
MM>>Давай мериться: кидай сюда код TreeView, в элементы которого, скажем, встроен ComboBox. У нас в проекте есть такая реальная задача. Давай, покажи код на Windows Forms, который это реализует.
B>Это неправильная задача. В бизнес приложениях вообще надо стараться не выдумывать нестандартные элементы управления. Потом и пользователям, и тем, кто будет поддерживать этот код, будет плохо.
Понятие "стандартных" и "нестандартных" элементов управления возникают, в основном, из-за технологии и инструментов, которые ты используешь. Да, для WinForms такое элемент "нестандартен". И ты именно так и думаешь.
Вот тебе и говорят, что WPF в этом смысле гибче. И то что в Формс "нестандартно" тут делается вообще без кодирования и становиться "стандартным".
Здравствуйте, IT, Вы писали:
IT>Технология отличается чрезвычайной гибкостью, но при этом весьма высоким порогом вхождения.
Я бы этот порог нарисовал примерно как параболоиду — вначале вроде бы всё легко, но как только нужны средней сложности кастомизации, порог резко взлетает вверх. Причём поднятие по графику не умаляет сложности (график-то бесконечный! ), т.к. написание каждого нетривиального темлита превращается в разработку шаттла с нуля.
IT> Скорее всего компании, занимающиеся UI компонентами, наклепают компонентов попроще и подоступнее в использовании и будет всем счастье.
Вот, собсно, и ответ — технология "натянута на рынок", сильно завышая требования к разработчикам. Что-то стало гибче (как всегда, не то, что нужно), но тупой перенос "кода" в "декларации" родил ужа-с-ежом — вычурные, громоздкие конструкции, заменяющие трёхстрочный код. На мой взгляд, МС опять выдала "огонь и движение", причём неслабый такой огонь. Хочу обратно в мир ВыньФормс!
Здравствуйте, matumba, Вы писали:
M>Вот, собсно, и ответ — технология "натянута на рынок", сильно завышая требования к разработчикам. Что-то стало гибче (как всегда, не то, что нужно), но тупой перенос "кода" в "декларации" родил ужа-с-ежом — вычурные, громоздкие конструкции, заменяющие трёхстрочный код. На мой взгляд, МС опять выдала "огонь и движение", причём неслабый такой огонь. Хочу обратно в мир ВыньФормс!
Имея довольно таки не плохой опыт работы с WinForms (вплоть до создания своих элементов управления с интеграцией в дизайнер форм), сейчас (после Silverlight) возвращаться на него очень даже не охота. Первое время все казалось сложным, но стоит только разобраться — не так и страшно. Хотя, может сыграл момент ограниченности Silverlight. WPF более богат возможностями, что поначалу может немного пугать
p.s. При большом желании можно так же все в коде писать. Хотя если привыкнуть к XAML, то оказывается очень удобно. Можно так же посмотреть на Expression Blend в плане рисования UI
Здравствуйте, MozgC, Вы писали:
MC>Ваши мысли? Приживется? Будет ли мейнстримом? Глянул вакансии — на данный момент не сильно востребован. Вот интересно как будет в будущем.
WPF уже давно прижился. Он очень хорошо подходит для написания всяких бизнес приложений. Люблю его за то, что UI легко кастомизируется и приложение выглядит современным, при этом не приходится использовать всякие левые контролы усложняющие продукт: 90% необходимого уже есть. В сочетании c MVVM продукт получается очень гибким и грамотно структурированным, что полезно с точки зрения дальнейшего развития.
Ложка дегтя:
* Производительность, обходится написанием критичных компонент на C++
* Отсутствие единого подхода к разработке, кто-то пишет обработчики событий в View классе потому-что студия сама провоцирует к этому, кто-то во ViewModel классе, кто-то настраивает UI из кода, кто-то из XAML, в результате может быть бардак
* Тяжелый deployment
* Бывают глюки на слабом или старом железе
Если нам не помогут, то мы тоже никого не пощадим.
), т.к. написание каждого нетривиального темлита превращается в разработку шаттла с нуля.
