Каков Ваш опыт с отказом от MVVM для находящейся в UserControl архитектуры WPF?
Кажется, что Вы пытаетесь сделать что-то, любят, захватывают самый высокий приоритетный объект в очереди, которая уже не заботится о другим процессом.
А вероятное решение состоит в том, чтобы добавить где пункт, ограничивающий его необработанными запросами:
select * from queue where flag=0 order by id desc for update;
update queue set flag=1 where id=:id;
--if you really want the lock:
select * from queue where id=:id for update;
...
Хотелось бы надеяться, вторая транзакция заблокируется, в то время как обновление флага происходит, затем это сможет продолжиться, но флаг ограничит его следующим в строке.
также вероятно, что с помощью уровня сериализуемой изоляции, можно получить результат, который Вы хотите безо всего этого безумия.
В зависимости от природы Вашего приложения, могут быть лучшие способы реализовать это, чем в базе данных, такой как канал LIFO или FIFO. Кроме того, может быть возможно инвертировать порядок, что Вам нужны они в, и использовать последовательность, чтобы гарантировать, что они обрабатываются последовательно.
6 ответов
мы можем наследовать наши не-XAML UserControls друг от друга
Я не понимаю. Что насчет того, что MVVM исключает наследование?
мы используем столько кода программной части, сколько хотим, что ускоряет разработку
Код программной части хорош, если это код, связанный с представлением. т.е. не бизнес-логика, которую вы хотите проверить. Разделение проблем и все такое.
Вы все еще можете делать MVVM, делая все в коде - даже свое представление. MVVM - это не про нулевой код. Речь идет о разделении проблем и выгод, которые вы получаете от этого. Если вам не нужно разрабатывать представления в Blend, то вы, безусловно, можете реализовать большую часть или все представление в виде кода. Черт возьми, даже если вам действительно нужно выполнять работу в Blend, есть определенная часть вашего представления, которая все еще может быть представлена в виде кода. Вам просто нужно оценить компромиссы и принять осознанные и обоснованные решения.
присоединение инфраструктурных элементов управления непосредственно к нашему классу модели, полученному от веб-службы, устраняет десятки мелких проблем с привязкой, которые у нас были при привязке Infragistics к ObservableCollections
] Элементы управления Infragistics очень плохие. Вот, я это сказал. Если это вариант, не используйте их. Если это не вариант (и я тоже был в этом положении), вы обычно можете обойти многие проблемы с привязанным поведением и другими методами. Да, это хлопотно, но не вините MVVM - обвиняйте Infragistics в создании набора элементов управления, который так сильно расходится с платформой WPF.
даже в обычном WPF отсутствие ObservableCollections создает такие проблемы, как невозможность создания простое меню, уходи
Я не Я вообще не понимаю этот момент. ObservableCollections являются частью WPF, а не MVVM. И, прочитав ваш вопрос (опять же - я ответил на него вскоре после того, как вы его отправили), я бы сказал, что это просто ваше непонимание того, как работает WPF - никакого отношения к MVVM.
мы заменяем метод EventAggregator. По одному с прямыми событиями с использованием UserControls и кода, который устраняет все виды проблем с событиями
Правильный инструмент для правильной работы. Если вы можете использовать прямые события, вы можете сделать это независимо от того, используете ли вы MVVM или нет. MVVM никоим образом не требует использования шаблона агрегатора событий, поэтому снова ваша точка зрения неясна. Шаблон агрегатора событий можно использовать для обеспечения совместной работы различных компонентов во время выполнения без каких-либо зависимостей во время компиляции. Используя стандартные события CLR, вы повторное создание сильных зависимостей между вашими компонентами. Если вы когда-нибудь захотите использовать их по отдельности, у вас будет чертовски много времени.
В общем, это не столько аргумент против MVVM, сколько недостаток понимания. Я думаю, вы плывете против течения, и я бы посоветовал вам присмотреться к MVVM. Это не серебряная пуля или универсальный шаблон, но он, несомненно, может помочь создать фантастическую основу для ваших приложений WPF / SL при правильном использовании.
Я попробовал это и в итоге вернулся к MVVM. В конечном итоге вы получите тот же беспорядок, управляемый событиями, с которым вы всегда были в Windows Forms. Если мне никогда не придется делать еще один myLabel.Text = this.MyLabelText , я буду счастлив.
Не поймите меня неправильно - MVVM труднее придерживаться, и вы действительно должны знать WPF, чтобы реализовать это .
Вы многое теряете, не используя его, в том числе возможность использовать Expression Blend для стилизации элементов управления и шаблонов данных.
Hey, whatever works for you. It's all too easy to get religious about this stuff. My apps slide into spaghetti code unless I pay pretty strict attention to Separation of Concerns, but that doesn't mean MVVM is the only way to go. If you've got an app that works, and one that you can change without a bunch of cascading side effects, then I'd say go with it.
I would respectfully disagree (no downvote) with Anderson Imes on one point: I don't find MVVM difficult to stick with; I find it very easy. To me, it is the simplest and most natural approach to designing WPF apps. I use it within the framework of Composite WPF (Prism), which provides a very robust framework for partitioning complex apps.
I have written a CodeProject article on implementing MVVM in a real-world app. Hopefully, people just getting into MVVM will find it helpful.
Модель представления хороша тем, что упрощает привязку данных. Привязка данных не покрывает все, что вам нужно сделать, поэтому некоторый код, прикрепленный к XAML, удобен.
По моему опыту, сочетание модели представления и присоединения к событиям, кажется, выполняет свою работу, пока не будет реализован более чистый подход. если требуется.
РЕДАКТИРОВАТЬ:
Присоединение к событиям не обязательно нарушает модель MVVM, если вы используете обработчик событий для перенаправления события в логику обработчика в вашей модели представления или в каком-либо другом ответственном объекте.
Есть преимущества на чистую привязку данных, так как вам будет проще создавать разные скины XAML, использующие одну и ту же модель представления. Одним из примеров является наличие оболочки отладки, которая раскрывает некоторые внутренние механизмы, помогающие в разработке, и рабочую оболочку, которая является конечным продуктом. Различные представления XAML могут быть привязаны к одной и той же модели представления.
Я начал создавать приложения WPF в FFA (бесплатный для всех) шаблон проектирования, и я не вернусь к нему даже для небольших проектов. Хотя кажется, что вы более продуктивны, переходя прямо к исходному, голому пользовательскому интерфейсу, я пришел к выводу, что это скорее восприятие производительности, потому что вы получаете мгновенное удовлетворение .
Рассмотрим: TextBlock.Text = "HelloWorld" . Нет ViewModel для построения, без склеивания V и VM или настроек привязки. Нажмите F5, и мы увидим «HelloWorld» во всей красе. Моя проблема с этим многогранна. Вот пара моих самых больших проблем:
Разделение задач . Без него код навигации, расширяемость и общее обслуживание сильно затруднено. Добавление функция приложения будет больше похоже на книга "выбери свое приключение" или упражнения в квантовой физике, чем это действительно что-то делает. Если у вас есть предсказуемый способ создайте свое приложение, у вас есть предсказуемый способ работы с ним.
Гибкость пользовательского интерфейса . При использовании шаблона FFA я обнаружил умение разрабатывать UI в моем приложений было почти невозможно. Слишком много раз у меня был контроль, я не мог проектировать в Blend. Было бы просто дайте красную рамку с исключение. Некоторый код программной части у меня был использовал что-то еще, чего не было можно использовать в режиме разработки, вызывая вопрос. Волшебный переход на MVVM исправлены все мои проблемы с Blend. Если я получу красная рамка в Blend сейчас, Я ЗНАЮ это проблема с моей презентацией код. Ничего другого.
Таким образом, использование FFA может быстро вывести ваш V1 на рынок, но пользователи PHB будут удивляться, почему v1.5 займет в четыре раза больше времени, чем v1. Мы все были там :)
Я думаю, что если вы хотите сделать что-то подобное, я бы работал с незаметными элементами управления, где вы определяете пользовательский интерфейс «ЧАСТИ», что делает его очень легко смешиваемым. Вы получаете ссылку на элементы управления пользовательского интерфейса через OnApplyTemplate. Эти элементы управления полностью стилизованы и наследуются. Это ваше представление, в котором вы будете использовать эти элементы управления и извлекать данные из привязки, передавая их своим незаметным элементам управления. Представление, IMO, всегда должно быть связующим звеном для привязки виртуальной машины к этим типам элементов управления.
Для элементов управления Infragistics, с которыми у вас возникли проблемы, при условии, что вы используете Prism, вы должны создать для него пользовательский адаптер региона. Это позволяет вам ТОЧНО закодировать, как элементы управления будут добавлены в Infragistics. Никаких привязок. Внедрение представления будет работать так же, как вы привыкли, как только вы его встроите.
Я видел, как у некоторых людей возникали подобные проблемы в MVVM, но я считаю, что это просто слишком буквально воспринимается MVVM. Посланник не все уладит. В моем приложении с ~ 40 видами (и увеличивающемся) есть около 5 составных событий. Я наследую элементы управления, я использую внедрение представлений для вещей, которые даже не являются панелями или элементами управления содержимым. Иногда у меня есть код / события, связанные с обработкой кода, связанные с презентацией ... И ... на самом деле, я защищаю MVVM и не говорю @ $ &% о тестировании :)
но я считаю, что это просто слишком буквально воспринимать MVVM. Не все удается уравнять. В моем приложении с ~ 40 видами (и увеличивающемся) есть около 5 составных событий. Я наследую элементы управления, я использую внедрение представлений для вещей, которые даже не являются панелями или элементами управления содержимым. Иногда у меня есть код / события, связанные с обработкой кода, связанные с презентацией ... И ... на самом деле, я защищаю MVVM и не говорю @ $ &% о тестировании :) но я считаю, что это просто слишком буквально воспринимать MVVM. Посланник не все уладит. В моем приложении с ~ 40 видами (и увеличивающемся) есть около 5 составных событий. Я наследую элементы управления, я использую внедрение представлений для вещей, которые даже не являются панелями или элементами управления содержимым. Иногда у меня есть код / события, связанные с обработкой кода, связанные с презентацией ... И ... на самом деле, я защищаю MVVM и не говорю @ $ &% о тестировании :)Я не согласен с этим, Я работал над крупномасштабным бизнес-приложением, используя WPF, MVVM, WCF и элементы управления Telerik. Вначале использовать MVVM было немного сложно, но как только мы определились с дизайном и каркасом модели представления, все стало очень просто. Повторное использование стало очень легко достижимым, и время разработки также сократилось.
Более того, было очень легко полностью изменить элементы управления; в некоторых местах мы использовали базовые элементы управления WPF, которые позже заменили элементами telerik, и наоборот (поскольку в некоторых местах нам не требовались тяжелые элементы telerik, такие как GridView). Я могу сказать, что при необходимости мы могли бы легко заменить все элементы управления telerik на другие элементы управления сторонних производителей или родные элементы управления WPF в любое время.
Но да, нам пришлось применить некоторые обходные пути при использовании элементов управления telerik и написать некоторый код в codebehind для решения некоторых проблем (ошибок в telerik); весь этот код был чисто презентационной логикой.