|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Пусть есть иерархическая модель (модель, состоящая из других моделей) - Model3 в коде ниже. Как сделать для этой модели модель представления? При этом эта модель представления должна представлять в виде своих свойств не свойства нижележащих моделей представления, а сами эти нижележащие модели представления. Мой вариант показан в коде ниже как ViewModel3. На закомментированный код прошу пока не обращать внимания. Проблема в нём в том, что этот вариант содержит дублирование данных. ViewModel3 содержит не только Model3, которая содержит Model1 и Model2, но и ViewModel1 и ViewModel2, которые тоже содержат Model1 и Model2. В результате, при изменении свойства ViewModel1 (которое принадлежит ViewModel3) я должен не только изменить поле vm1, лежащее в основе этого свойства, но и поле m3. Это нужно сделать потому, что логика изменения ViewModel3 подразумевает отображение этих изменений на Model3. Т. е. главное, это изменить свойства Model3, лежащей в основе - не зря эта модель передаётся в конструкторе. Изменить Model3 (в виде поля m3) я могу либо изменив все свойства соответствующей модели m1, представляющей поле m3: Код: c# 1.
либо изменив саму эту модель: закомментированный код Код: c# 1.
Минус тут в том, что я должен в любом случае изменить ещё и поле vm1, т. к. иначе произошедшие изменения в m3 не отобразятся в соответствующих представлениях для vm1, которые отображают часть данных из m3 по логике вещей. Так вот, у меня такое ощущение, что у меня неправильный дизайн. Кажется, лишним является создание в конструкторе ViewModel3: Код: c# 1.
Или, может, лишним является хранение модели Model3 Код: c# 1.
? Из-за этого появляется дублирование данных и я должен в каждом сеттере делать два изменения - для каждого свойства составной модели и для каждого свойства в виде отдельной модели представления. При этом реально нужные изменения - только для модели (у меня это Model3 m3), а изменения для ViewModel1 vm1 - только для отображения результата. Есть какой-нибудь лучший подход? Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 08:33 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
авторлибо изменив саму эту модель: закомментированный код Код: c# 1.
Тут ещё проблема в том, что, чтобы это работало, модель представления ViewModel1 должна предоставить свою модель Model1, лежащую в основе, что отображено у меня в закомментированном коде ViewModel1. Т. е. ещё один костыль. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 08:36 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Есть какой-нибудь лучший подход? Есть, перестать тренироваться "на кошках", поставить перед собой реальную задачу и ее решить! Только так до Вас дойдет, что ЧИСТЫЙ MVVM это один большой костыль, который в реальный проектах НЕЖИЗНЕСПОСОБЕН! ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 09:05 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRuser7320Есть какой-нибудь лучший подход? Есть, перестать тренироваться "на кошках", поставить перед собой реальную задачу и ее решить! Только так до Вас дойдет, что ЧИСТЫЙ MVVM это один большой костыль, который в реальный проектах НЕЖИЗНЕСПОСОБЕН! Да. Я начитался статей типа этой . В них предлагается делать четырёх-, пяти- и более слоевые конструкции. Авторы подобных статей бодро говорят, как у них с такими конструкциями всё выходит гладко и чисто. Только у меня сомнения закрадывается, что если в трёх слоях уже многие путаются, то когда намешано 4 слоя и более, да ещё дело касается крупных приложений, типа того же Офиса или Автокада, то всё становится ещё хуже. Авторы почти никогда не говорят, какой сложности были у них проекты. Может, это сраные мессенджеры и проверяльщики статусиков во вконтактиках? У вас вот какие подходы для борьбы с MVVM? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 10:59 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320У вас вот какие подходы для борьбы с MVVM? Неправильно спросил. Я хотел спросить, что бы вы предложили мне в моём случае? Модель, состоящая из двух других моделей. В представлении это должно быть представлено так: - модель, состоящая из других моделей - это контейнер, - модели, составляющие эту сложную модель - отдельные представления (скажем, на шаблонах данных). Для меня логично было сделать модель представления для таких представлений в виде такой же включающей еирархии - VM3 имеет поля в виде VM1 и VM2. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 11:01 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320ично было сделать модель представления для таких представлений в виде такой же включающей еирархии - VM3 имеет поля в виде VM1 и VM2. Совершеенно верно, и что останавливает? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 11:07 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Пусть есть иерархическая модель (модель, состоящая из других моделей) - Model3 в коде ниже. Как сделать для этой модели модель представления? При этом эта модель представления должна представлять в виде своих свойств не свойства нижележащих моделей представления, а сами эти нижележащие модели представления. Тоже задавался такими вопросами, в итоге вышел на персистентные структуры данных Ниже сложности C(ln(N)) на единичное изменение по древовидным структурам не обеспечишь, но это очень даже приемлемо без поддержки языка программирования управлять такими структурами очень трудно (всё время хочется где нить хакнуть) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 13:23 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Есть какой-нибудь лучший подход?а525... 1. Читать Фаулер "Рефакторинг". 2. Данные хранить в модели как она есть. Модель лучше сразу приспособить для датабиндинга, чтобы не писать потом для неё обёртки. 3. Логику разместить в UserControl code-behind. Если возникают проблемы с повторным использованием логики в code-behind, то выносить логику в отдельный класс (выделение класса по Фаулеру). Логику оформлять в виде ICommand или EventHandler, в зависимости от потребностей. Начни с этого. Дальше сам всё поймёшь. Верь мне... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 13:26 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320 Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Привязывай контролы непосредственно к этой структуре данных. Обёртки не нужны. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 13:34 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей К2. Данные хранить в модели как она есть. Модель лучше сразу приспособить для датабиндинга, чтобы не писать потом для неё обёртки. Оч интересно, а как енто "приспособить для датабиндинга"? Алексей К3. Логику разместить в UserControl code-behind. Если возникают проблемы с повторным использованием логики в code-behind, то выносить логику в отдельный класс (выделение класса по Фаулеру). Логику оформлять в виде ICommand или EventHandler, в зависимости от потребностей. Еще интересней, т.е. если у меня 20 формочек, в среднем на каждой висит 20 евентов, то Вы предлагаете 400 евентов в один класс загнать? А если завтра война? Такой жирный класс через границу не унесешь! Алексей КНачни с этого. Дальше сам всё поймёшь. Верь мне... Извините, но пока даже с трудом не верится. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 13:54 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей К3. Логику разместить в UserControl code-behind. Нет. Алексей КЛогику оформлять в виде ICommand. Да. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 14:03 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кuser7320Есть какой-нибудь лучший подход?а525... 1. Читать Фаулер "Рефакторинг". 2. Данные хранить в модели как она есть. Модель лучше сразу приспособить для датабиндинга, чтобы не писать потом для неё обёртки. 3. Логику разместить в UserControl code-behind. Если возникают проблемы с повторным использованием логики в code-behind, то выносить логику в отдельный класс (выделение класса по Фаулеру). Логику оформлять в виде ICommand или EventHandler, в зависимости от потребностей. Начни с этого. Дальше сам всё поймёшь. Верь мне... Don't you wanna say MVVM is sucks? B...b...but these and those guys say MVVM is fucking great... Okay ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 14:24 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кuser7320 Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Привязывай контролы непосредственно к этой структуре данных. Обёртки не нужны. Я хочу свою работу как портфолио использовать в том числе. Как считаешь, что следует писать в резюме - "умею в MVVM" или не стоит? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 14:26 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоАлексей К3. Логику разместить в UserControl code-behind. Нет. Алексей КЛогику оформлять в виде ICommand. Да. В логике проблем нет. Проблема в в том, как представить иерархические модели в моделях представления в рамках WPF's MVVM. Я гуглил-гуглил, ничего толкового не нашёл. Иерархические модели представления в WPF хороши тем, что в представлениях они выглядят как контейнеры, которые состоят из контент презентеров, которые ссылаются на дата темплиты - и всё выглядит логично. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 14:31 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRАлексей К2. Данные хранить в модели как она есть. Модель лучше сразу приспособить для датабиндинга, чтобы не писать потом для неё обёртки. Оч интересно, а как енто "приспособить для датабиндинга"? Я думаю, он имел ввиду OnPropertyChanged и т. п. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 14:31 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRАлексей К2. Данные хранить в модели как она есть. Модель лучше сразу приспособить для датабиндинга, чтобы не писать потом для неё обёртки. Оч интересно, а как енто "приспособить для датабиндинга"?INotifyPropertyChanged. James Bond FRАлексей К3. Логику разместить в UserControl code-behind. Если возникают проблемы с повторным использованием логики в code-behind, то выносить логику в отдельный класс (выделение класса по Фаулеру). Логику оформлять в виде ICommand или EventHandler, в зависимости от потребностей. Еще интересней, т.е. если у меня 20 формочек, в среднем на каждой висит 20 евентов, то Вы предлагаете 400 евентов в один класс загнать? А если завтра война? Такой жирный класс через границу не унесешь! Про 20 и 400 не понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 14:55 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320В логике проблем нет. Проблема в в том, как представить иерархические модели в моделях представления в рамках WPF's MVVM. Я гуглил-гуглил, ничего толкового не нашёл. Я тебе в соседней теме давал рецепт, там всё есть. Всё работает на штатном HierarchicalDataTemplate. Модель классическая: Код: c# 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 14:58 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Иерархические модели представления в WPF хороши тем, что в представлениях они выглядят как контейнеры, которые состоят из контент презентеров, которые ссылаются на дата темплиты - и всё выглядит логично.У тебя проблема в первую очередь из-за того, что ты смешиваешь в одних классах логику и данные. Помни: 1. Биндинг можно делать через RelativeSource. 2. У ICommand есть CommandParameter, в который можно передать SelectedItem какого-либо контрола. И в данном случае даже пофиг, живёт логика в code-behind или где-то ещё. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 15:00 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
вдогонку: По сути, предлагается завести под логику в ICommand-ах отдельную ViewModel, если разместить это в code-behind религия не позволяет. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 15:03 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоuser7320В логике проблем нет. Проблема в в том, как представить иерархические модели в моделях представления в рамках WPF's MVVM. Я гуглил-гуглил, ничего толкового не нашёл. Я тебе в соседней теме давал рецепт, там всё есть. Всё работает на штатном HierarchicalDataTemplate. Модель классическая: Код: c# 1. 2. 3. 4. 5. 6.
Я уже не про дерево говорю в этой теме. Наверное, вас смутило слово "иерархические". Но в примере в первом посте видно, что у меня не дерево. Иерархия заключается во включении - т. е. одна модель представления является полем или свойством в другой модели представления. Вот в чём вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 15:25 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Квдогонку: По сути, предлагается завести под логику в ICommand-ах отдельную ViewModel, если разместить это в code-behind религия не позволяет. Зачем заводить два файла с кодом вместо одного? И почему логика только в командах? А в свойствах? А в OnPropertyChanged? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 15:29 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кuser7320Иерархические модели представления в WPF хороши тем, что в представлениях они выглядят как контейнеры, которые состоят из контент презентеров, которые ссылаются на дата темплиты - и всё выглядит логично.У тебя проблема в первую очередь из-за того, что ты смешиваешь в одних классах логику и данные. Помни: 1. Биндинг можно делать через RelativeSource. 2. У ICommand есть CommandParameter, в который можно передать SelectedItem какого-либо контрола. И в данном случае даже пофиг, живёт логика в code-behind или где-то ещё. А предложить подход в рамках MVVM кто-нибудь может? Там всего-то дублирование данных у меня (мой пример кто-нибудь смотрел?). У меня такое ощущение, что я просто не так классы написал и что в рамках MVVM там должно всё разруливаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 15:31 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Алексей Кпропущено... У тебя проблема в первую очередь из-за того, что ты смешиваешь в одних классах логику и данные. Помни: 1. Биндинг можно делать через RelativeSource. 2. У ICommand есть CommandParameter, в который можно передать SelectedItem какого-либо контрола. И в данном случае даже пофиг, живёт логика в code-behind или где-то ещё. А предложить подход в рамках MVVM кто-нибудь может? Там всего-то дублирование данных у меня (мой пример кто-нибудь смотрел?). У меня такое ощущение, что я просто не так классы написал и что в рамках MVVM там должно всё разруливаться.А чем это не MVVM? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 15:42 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Алексей Квдогонку: По сути, предлагается завести под логику в ICommand-ах отдельную ViewModel, если разместить это в code-behind религия не позволяет. Зачем заводить два файла с кодом вместо одного?Где кто писал про "файл"? user7320И почему логика только в командах? А в свойствах? А в OnPropertyChanged?Ну если надо - так надо, пиши обёртки... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 15:44 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кuser7320пропущено... А предложить подход в рамках MVVM кто-нибудь может? Там всего-то дублирование данных у меня (мой пример кто-нибудь смотрел?). У меня такое ощущение, что я просто не так классы написал и что в рамках MVVM там должно всё разруливаться.А чем это не MVVM? "Обычно" модель представления (МП) "пробрасывает" данные модели в представление. Т. е. в свойствах МП в геттерах делается вызов свойств модели и результат возвращается: get { return model.Property; } В сеттерах же точно также присваивается значение не свойству МП, а по сути свойству М (модели): set { model.Property = value; } Т. е. в МП модель является backing field, хранящим свойства МП. Но это для простых случаев - когда нет никакой иерархии в моделях и моделях представлений. А когда иерархия, то ни в каких джошесмитовских букварях ничего такого не разобрано. И вообще нигде не разобрано. А я задал ПРОСТОЙ ВОПРОС: модель, у которой поля - другие модели. Как для неё сделать МП с таким же включением - МП, с полями в виде других МП? У меня получилось так Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
Здесь данные дублируются, а не пробрасываются. При этом М по-прежнему является backing field: private Model3 m3; Но ведь надо ещё и модели Model1 и Model2 как-то представлять. Поэтому для них ещё по полю создаю - vm1 и vm2. И в каждом таком поле тоже хранится по копии модели. Итого уже две копии каждой из составляющих моделей хранится во ViewModel3. Например, модель Model1 хранится - одна в private Model3 m3 в виде m3.M1, а другая - в private ViewModel1 vm1; в виде vm1.m1. Теперь когда у меня прилетает новая ViewModel1 в сеттер ViewModel3, я должен обновить модель и там, и там. В результате сеттер превращается не в простое Код: c# 1.
а в монструозное и костыльное Код: c# 1. 2. 3. 4. 5. 6.
Причём никакие эти про такие проблемы не пишут. Я так понимаю, что они знают какой-то секрет или для них настолько элементарно представить мои иерархические модели в моделях представления, что они даже не считают нужным про этом упомянуть. Бубнят про какие-то слои, про "слишком много логики в VM", а про то, с чем должны сталкиваться каждый день и что я привёл - ни слова. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 16:18 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кuser7320вдогонку: По сути, предлагается завести под логику в ICommand-ах отдельную ViewModel, если разместить это в code-behind религия не позволяет. Зачем заводить два файла с кодом вместо одного?Где кто писал про "файл"? А у тебя "отдельную ViewModel" и code-behind в одном файле находятся? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 16:20 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Наверное, вас смутило слово "иерархические". Но в примере в первом посте видно, что у меня не дерево. Иерархия заключается во включении - т. е. одна модель представления является полем или свойством в другой модели представления. Вот в чём вопрос. У тебя каша в голове. Вью модель одна для одного представления, никакой вложенности других вью моделей не должно быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 16:33 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
А не composite ли это application ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 16:42 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоuser7320Наверное, вас смутило слово "иерархические". Но в примере в первом посте видно, что у меня не дерево. Иерархия заключается во включении - т. е. одна модель представления является полем или свойством в другой модели представления. Вот в чём вопрос. У тебя каша в голове. Вью модель одна для одного представления, никакой вложенности других вью моделей не должно быть. Если будет вложенность, то можно в представлении делать так (грубо без деталей): Код: xml 1. 2. 3. 4. 5. 6. 7. 8.
И для каждой VM есть свой DataTemplate. В результате ты юзер конотролы можешь собирать из одних контент презентеров. А внутри этих DataTemplate ещё свои ContentPresenter, которые тоже байндятся к моделям представления, для которых тоже есть свои DataTemplate. По-моему, всё просто. А если по-твоему и "Вью модель одна для одного представления, никакой вложенности других вью моделей не должно быть", то придётся на мою модель, которая состоит из других моделей, делать вью модель, которая будет содержать в себе ВСЕ СВОЙСТВА всех составляющих её моделей. Т. е. так: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 16:49 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Если будет вложенность, то можно в представлении делать так (грубо без деталей) Нет. Представление не должно отруливать алгоритмом выбора вью модели. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 16:56 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320 Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
А зачем вообще вот этот код? С какой целью подменять viewmodel на ходу, причем использовать состоние привязанной к ней модели в качестве значения? ViewModel это ж фактически valueconverter для сложного типа. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 17:09 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperuser7320 Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
А зачем вообще вот этот код? С какой целью подменять viewmodel на ходу, причем использовать состоние привязанной к ней модели в качестве значения? ViewModel это ж фактически valueconverter для сложного типа. Это вообще клинический бред. Тут даже нечего комментировать. Вью модели должен накидывать либо отдельный сервис, либо сервис-локатор (в этом случае вью модель указывается прямо в замле). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 17:18 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоuser7320Наверное, вас смутило слово "иерархические". Но в примере в первом посте видно, что у меня не дерево. Иерархия заключается во включении - т. е. одна модель представления является полем или свойством в другой модели представления. Вот в чём вопрос. У тебя каша в голове. Вью модель одна для одного представления , никакой вложенности других вью моделей не должно быть.Выделил на всякий, вдруг не заметит... user7320, ну ты если мне не веришь, ну МСУ то можно верить. Или тоже нельзя? Тут можно изъепнуться, и таки построить иерархию вьюмоделей аналогичную иерархии моделей, но зачем плодить бесполезный код? Его и без тебя на планете хватает. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 17:52 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей КТут можно изъепнуться, и таки построить иерархию вьюмоделей Когда я читаю user7320, у меня иногда возникает мысль, что он просто парень-рубаха: пишет код чисто для самозаёба. Это нормально :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 18:26 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperА зачем вообще вот этот код? С какой целью подменять viewmodel на ходу, причем использовать состоние привязанной к ней модели в качестве значения? ViewModel это ж фактически valueconverter для сложного типа. Алексей КмсущкоУ тебя каша в голове. Вью модель одна для одного представления , никакой вложенности других вью моделей не должно быть.Выделил на всякий, вдруг не заметит... user7320, ну ты если мне не веришь, ну МСУ то можно верить. Или тоже нельзя? Тут можно изъепнуться, и таки построить иерархию вьюмоделей аналогичную иерархии моделей, но зачем плодить бесполезный код? Его и без тебя на планете хватает. Модель представляет из себя композицию включением других моделей: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Как сделать ВМ для Model2, чтобы можно было редактировать её свойства? Т. е. на свойство Ma должна в сеттер прилетать модель Model1. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 19:46 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Модель представляет из себя композицию включением других моделей. Ты определись, модель или вью модель. В кучу смешалось всё, люди, кони... user7320Как сделать ВМ для Model2... Остановись. Нельзя сделать вью модель для модели. Можно наоборот - вью модель может ссылаться на n моделей. Читай про mvvm, доколе будешь тупит-то? Вью модель делается для представления и только для него. P.S. Изучи вот этот рецепт , там я разжевываю по полочкам, как и что должно быть. Всё. Больше ничего другого выдумывать не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 20:13 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Ребята, вмето того что бы штудировать "Фаулеров" и иже с ним, почитайте лучше "совковые" книги по системному анализу и по системотехнике, в ангоязычной литературе это называется - системная инженерия. Именено там изложенны базовые принципы постоения систем, которые имеют практическую ценность. Все "фаулеровские выкладки", паттерны и прочая муть, это частные случаи систмной инженерии! Количество звеньев(слоев), так или иначе коррелирует с теорией надежности, хотя на первый взгляд это не очевидно. Что из этого следует? Всем нам, что бы прикрывать яйца от мороза, нужно носить штаны, но штаны не долговечны, имеют особенность терять эстетический вид, загрязняться, рваться и т.д. Что бы избежать неурядиц, нужно иметь запасные штаны, это называется - дублирование. Собственно вопрос - почему не завести себе 100 штанов? Дело в том, что как показывает практика, будь у Вас 100 штанов, носить Вы будете все равно - трое четверо, пятые уже будут лишними! И это математически подтверждено - максимум может быть оправдано четырехкратное дублирование! Есть конечно исключения, если Вы Филипп Киркоров, то одевать каждый день новые штаны это часть Вашего имиджа, это Ваш заработок, но в обыденной жизни такой подход не катит. Теперь ближе к теме. При постоении ситемы, максимум должно быть ЧЕТЫРЕ абстрогируемых звена. Если строим клиент-серверную систему, работающую через веб-сервисы, то уже изначально имеем 2 слоя - уровень СУБД и слой веб-сервисов. Соответственно, если в клиентском приложении Вы начнете изобретать больше двух слоев, то эффективность такой реализации начнет зезко падать! Если Ваше приложение имеет непосредственный доступ к СУБД, то реализация трех слоев вполне может быть оправдана. Теперь ближе к программированию. Не даром конструктор в студии при ператаскивании данных из источника создает источники биндинга в ресурсах. И почему-то в проекте создается класс App откуда все и стартует и от куда можно делать все биндинги! Это своего рода реализация синглтона. Это абсолютно с точки зрения системной инженерии правильно! Есть нейкий сингл в приложени вокруг которого создается некая логическая обвязка. Т.е. в два звена можно все вложить, с доступом к СУБД приделываем третье звено в виде ОРМ, дао и иже с ними, зачем еще что-то лепить? Инженеры в M$ это видимо прейрасно понимают, а разработчики поверх готового велосипеда всеми силами стараются прилепить еще один велосипед! Все сказанное - имхо неоднократно подтвержденное на практике. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 20:20 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRКоличество звеньев(слоев), так или иначе коррелирует с теорией надежности... Теперь ближе к теме. При постоении ситемы, максимум должно быть ЧЕТЫРЕ абстрогируемых звена... Если строим клиент-серверную систему, работающую через веб-сервисы, то уже изначально имеем 2 слоя - уровень СУБД и слой веб-сервисов.... Соответственно, если в клиентском приложении Вы начнете изобретать больше двух слоев, то эффективность такой реализации начнет зезко падать... Тебе бы самому книжек почитать. Особенно на тему отличия уровня (звена, tier) и слоя (layer). Когда придет просветвление, приходи сюда, объяснишь нам, как нужно писать код. P.S. На будущее. Если мы строим клиент-серверную систему, работающую через веб-сервисы, это 3-уровневая архитектура (клиент, сервер приложений и БД). Покури вот этот мануал, пора взрослеть http://codearticles.ru/articles/1522 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 20:30 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Мдя, с Вами коллега комунизьм еще долго бутем строить. Спасибо что заставили почувствовать себя молодым, но из Ваших ресурсов, первое что попалось: С чего бы выделенно именно ЧЕТЫРЕ абстрогируемых звена? И каких? Я угадал? Или пойдете может лучше книги заросшие пылью политаете? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 20:51 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRМдя, с Вами коллега комунизьм еще долго бутем строить. Спасибо что заставили почувствовать себя молодым, но из Ваших ресурсов, первое что попалось: С чего бы выделенно именно ЧЕТЫРЕ абстрогируемых звена? И каких? Я угадал? Или пойдете может лучше книги заросшие пылью политаете? James Bond FRМдя, с Вами коллега комунизьм еще долго бутем строить. Спасибо что заставили почувствовать себя молодым, но из Ваших ресурсов, первое что попалось: С чего бы выделенно именно ЧЕТЫРЕ абстрогируемых звена? И каких? Я угадал? Или пойдете может лучше книги заросшие пылью политаете? Тут речь не о звене (tier), а о слое (layer). Опять мимо, коллега :) P.S. Пока не поймешь разницу между tier и layer, разговора у нас никак не получится. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 20:57 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FR, N-уровневая / 3-уровневая архитектураПримером N-уровневого/3-уровневого архитектурного стиля может служить типовое финансовое Веб-приложение с высокими требованиями к безопасности. Бизнес-слой в этом случае должен быть развернут за межсетевым экраном, из-за чего приходится развертывать слой представления на отдельном сервере в пограничной сети. Другой пример – типовой насыщенный клиент, в котором слой представления развернут на клиентских компьютерах, а бизнес-слой и слой доступа к данным развернуты на одном или более серверных уровнях. Так что опять двойка ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:00 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоТут речь не о звене (tier), а о слое (layer). Опять мимо, коллега :) P.S. Пока не поймешь разницу между tier и layer, разговора у нас никак не получится. Хорошо коллега, раз уж решили начать с понятий - так и поступим. При проектировании выделяют три этапа: 1. Проетирование функциоанльной схемы. 2. Поточной. 3. Структурной схемы. По Вашему мнению, какая схама отображена? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:10 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоuser7320Модель представляет из себя композицию включением других моделей. Ты определись, модель или вью модель. В кучу смешалось всё, люди, кони... user7320Как сделать ВМ для Model2... Остановись. Нельзя сделать вью модель для модели. Можно наоборот - вью модель может ссылаться на n моделей. Читай про mvvm, доколе будешь тупит-то? Вью модель делается для представления и только для него. Что это значит? Что я должен сначала придумать представление, а потом писать для него вью-модель? Тогда покажите, как бы вы сделали вью-модель для моего варианта , когда представление представляет собой отображение модели Model4, свойство которой Model3 M3 можно изменить, прислав на это свойство другую Model3. Обычное обновление поля модели, ничего сложного. мсущкоP.S. Изучи вот этот рецепт , там я разжевываю по полочкам, как и что должно быть. Всё. Больше ничего другого выдумывать не нужно. Там только пример программы без комментариев. Это всё? Я там увидел дерево - это я уже разобрал. Ещё там есть грид с сотрудниками и возможностью их редактировать-добавлять. Это я тоже знаю. Ваш пример только портит использование Юнити - нихрена не понятно, что это за контейнеры такие и сервисы. Фактически, ваш пример завязан на Юнити - надо сначала изучить Юнити, а потом ваш пример. Лучше бы без Юнити. автор Код: c# 1. 2. 3.
Это не по МВВМу, но я и сам до этого догадался. Это тоже мне всё знакомо. А это что за непотребство?! автор Код: c# 1. 2. 3. 4. 5. 6. 7.
Почему представление грида обновляется ручками, а не через обновление нижележащей коллеции и привязки? Это не просто не по МВВМу, а вообще какой-то говнокод, как сказал бы МСУ. Но это фактически то и есть, что я делаю - обновляю дважды (это моё "дублирование данных"). Сначала нижележащие данные в модели, а потом вью-модель (точнее, у меня наоборот по ссылке ниже): http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1092795&msg=15975182 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:11 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRмсущкоТут речь не о звене (tier), а о слое (layer). Опять мимо, коллега :) P.S. Пока не поймешь разницу между tier и layer, разговора у нас никак не получится. Хорошо коллега, раз уж решили начать с понятий - так и поступим. При проектировании выделяют три этапа: 1. Проетирование функциоанльной схемы. 2. Поточной. 3. Структурной схемы. По Вашему мнению, какая схама отображена? Не ипи мне моск. Ты облажался с уровнями и слоями - если нет понимания что это такое (а его нет впринципе), о проектировании не может быть и речи. Сидеть с тобой надрачивать "понятия" у меня нет никакого желания, я этим занимаюсь тут на форуме с 2006 года. Если по делу есть что сказать - говори. Иначе в топку. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:15 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоJames Bond FRпропущено... Хорошо коллега, раз уж решили начать с понятий - так и поступим. При проектировании выделяют три этапа: 1. Проетирование функциоанльной схемы. 2. Поточной. 3. Структурной схемы. По Вашему мнению, какая схама отображена? Не ипи мне моск. Ты облажался с уровнями и слоями - если нет понимания что это такое (а его нет впринципе), о проектировании не может быть и речи. Сидеть с тобой надрачивать "понятия" у меня нет никакого желания, я этим занимаюсь тут на форуме с 2006 года. Если по делу есть что сказать - говори. Иначе в топку. Чтож коллега, как говорят - слив защитан! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:18 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRЧтож коллега, как говорят - слив защитан! :) Если тебе будет так легче, я не против :) P.S. Проблема кроется глубже: у тебя понимания ранее не было и сейчас нет. И ты не хочешь даже понять это, это еще хуже. Так что лучше тихонечко изучи мануал, который я тебе дал, чтобы хоть в следующий раз так не обосраться. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:21 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Что это значит? Что я должен сначала придумать представление, а потом писать для него вью-модель? Да как хочешь, так и придумывай. Суть остается сутью: есть вью и его личная вью модель. user7320Тогда покажите, как бы вы сделали вью-модель для моего варианта , когда представление представляет собой отображение модели Model4, свойство которой Model3 M3 можно изменить, прислав на это свойство другую Model3. Обычное обновление поля модели, ничего сложного. Тебе уже 100 раз разжевали, что и как нужно делать. Читать килобайты твоей шизофрении лень. И уж тем более что-то там делать за тебя. user7320Там только пример программы без комментариев. Это всё? Комментарии? А задницу салфеточкой не вытереть? )) user7320Ваш пример только портит использование Юнити - нихрена не понятно, что это за контейнеры такие и сервисы. Фактически, ваш пример завязан на Юнити - надо сначала изучить Юнити, а потом ваш пример. Лучше бы без Юнити. Да какая разница, какой DI контейнер использовать. Юнити или что-то еще. Ты суть улови, что тебе хотят донести по теме. user7320автор Код: c# 1. 2. 3.
Это не по МВВМу, но я и сам до этого догадался. Это тоже мне всё знакомо. Почему? Это нисколько не нарушает концепцию mvvm. user7320А это что за непотребство?! автор Код: c# 1. 2. 3. 4. 5. 6. 7.
Почему представление грида обновляется ручками, а не через обновление нижележащей коллеции и привязки? Это не просто не по МВВМу, а вообще какой-то говнокод, как сказал бы МСУ. Потому, чтобы ослабить связь представления и вью модели. Это ослабление делается через инжекцию в виде UI сервиса. Опять же, принцип MVVM не нарушен. Ты просто не дорос еще до этого "гавнокода". ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:30 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоПотому, чтобы ослабить связь представления и вью модели. Это ослабление делается через инжекцию в виде UI сервиса. Опять же, принцип MVVM не нарушен. Ты просто не дорос еще до этого "гавнокода". Что бы ослабить связь представления с вью-моделью мы лезем ручками в датагид? На кого рассчитан этот треш коллега? Я нисколько ни порицаю данный подход, но это явно не по MVVM-овски! ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 21:48 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRмсущкоПотому, чтобы ослабить связь представления и вью модели. Это ослабление делается через инжекцию в виде UI сервиса. Опять же, принцип MVVM не нарушен. Ты просто не дорос еще до этого "гавнокода". Что бы ослабить связь представления с вью-моделью мы лезем ручками в датагид? На кого рассчитан этот треш коллега? Я нисколько ни порицаю данный подход, но это явно не по MVVM-овски! Я уже понял, что для тебя слово UI сервис пустой звук. Что бы ослабить связь представления с вью-моделью, мы создаём слой (layer). По слогам повтори "la-yer". По сути, что-то подобие контроллера в MVC, который скармливает модель во вью. P.S. Изучи ссылку, которую я дал выше. Если не осилишь, начни таки с азов слоёв и уровней. Цирк ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 22:07 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Вот еще альтернатива UI сервиса (View сервиса) http://msdn.microsoft.com/en-us/magazine/jj694937.aspx P.S. Но по мне такой способ несет больше геморроя, чем пользы. Да и противник я код бехайнда, иначе это уже не MVVM. P.S2. James Bond FR, в следующий раз, когда захочешь что-то умное сказать, 10 раз подумай. А то я уже со счета сбился, сколько раз ты уже тут налажал :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 22:11 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоПочему представление грида обновляется ручками, а не через обновление нижележащей коллеции и привязки? Это не просто не по МВВМу, а вообще какой-то говнокод, как сказал бы МСУ. Потому, чтобы ослабить связь представления и вью модели. Это ослабление делается через инжекцию в виде UI сервиса. Опять же, принцип MVVM не нарушен. Ты просто не дорос еще до этого "гавнокода". Т. е. нормальный МВВМ не сделать, если не применить при этом кучу высокоуровневых абстракций и толстолобых паттернов? МВВМ не заводится без кучи костылей? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 04:53 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоuser7320Что это значит? Что я должен сначала придумать представление, а потом писать для него вью-модель? Да как хочешь, так и придумывай. Суть остается сутью: есть вью и его личная вью модель. Я придумывал вью модели так: брал модель с думал, как она должна выглядеть в представлении. Делал под придуманное вью модель. Что не так? У меня такое ощущение, что вы привязались к словам - т. е. мы говорим об одном и том же, но разными словами. И это, по МВВМу, вью модель знает о модели. Поэтому логично, что она должна создаваться с оглядкой на модель. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 05:08 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоВот еще альтернатива UI сервиса (View сервиса) http://msdn.microsoft.com/en-us/magazine/jj694937.aspx P.S. Но по мне такой способ несет больше геморроя, чем пользы. Да и противник я код бехайнда, иначе это уже не MVVM. P.S2. James Bond FR, в следующий раз, когда захочешь что-то умное сказать, 10 раз подумай. А то я уже со счета сбился, сколько раз ты уже тут налажал :) Коллега, Вас уже два раза ткнули носом в Ваши косяки, но судя по всему Вы из тех людей, которые с пеной у рта готовы доказывать свою не правоту. Еще раз - в чем смысл MVVM да и любого паттерна в принципе? Разделяй и влавствуй! С этим надеюсь согласны? Идея MVVM да и WPF(Silverlight) в целом - дизайнер рисует UI, прогер кодит. В итоге дизайнер биндит контролы на сущности и все работает. С этим надеюсь тоже согласны? Что произойдет если дизайнер изменит имя employeesGrid на MyEmployeesGrid? Правильно! Ваш метод отвалится! Какие к черту "UI сервисы"? Что это за бред вообще? Хотя я конечно прекрасно понимаю что это - тупой соскок, попытка скрыть непригодность MVVM в чистом виде, который не жизнеспособен о чем я говорил выше. На мой взгляд это очевидные вещи, которые Вы не желаете признавть из-за своих амбиций или по другим не известным мне причинам. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 05:18 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Тут кому-то не нравилось, что вью модель скомпонована из других вью моделей. Вот, другие люди совсем не против такого подхода: http://cocktail.ideablade.com/composing-view-models/ Вот то, что я писал выше Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 05:28 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Тут кому-то не нравилось, что вью модель скомпонована из других вью моделей. Вот, другие люди совсем не против такого подхода: http://cocktail.ideablade.com/composing-view-models/ Вот то, что я писал выше Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Единственное, что прямо здесь не показаны байндинги. Но там автор ниже поясняет, что он использует какой-то свой Caliburn.Micro фреймворк, который эти байндинги добавляет. Т. е. всё в чистом виде как у меня. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 05:33 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 05:47 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Тут кому-то не нравилось, что вью модель скомпонована из других вью моделей. Вот, другие люди совсем не против такого подхода: http://cocktail.ideablade.com/composing-view-models/ Вот то, что я писал выше Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Вместо ContentControl тут могли бы быть UserControl. Код: xml 1. 2. 3. 4. 5. 6. 7. 8.
После множества изысканий мы остановились на таком подходе для реализации "композитности". ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 05:52 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320 А Призма вообще за композицию представлений. Вся эта prism-байда отталкивается от неверного утверждения, мол приложения на "голом" WPF плохо разделяются на модули и вообще так себе: авторВ обработчике этой команды Execute при каждом выборе позиции происходит событие TickerSymbolSelected. TrendLine и NewsReader привязаны к нему, они ждут события TickerSymbolSelected и визуализируют свое содержимое, основываясь на выбранном биржевом коде. В данном случае приложение тесно привязано к каждому элементу управления. Для координации всех различных частей в интерфейсе пользователя имеется значительный объем логики. Также существует взаимозависимость между элементами управления. В силу этих зависимостей нет простого способа разбить приложение так, чтобы каждую из отдельных частей можно было разрабатывать отдельно. Для более удобного обслуживания все пользовательские элементы управления можно поместить в отдельную сборку, но это лишь выносит проблему из основного приложения в сборку элементов управления. В этой модели очень сложно вносить значительные изменения или добавлять новые функции.Автор сего творения не знаком с DependencyProperty, DataBinding и прочими возможностями WPF. Как ему можно верить? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 06:05 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кuser7320Тут кому-то не нравилось, что вью модель скомпонована из других вью моделей. Вот, другие люди совсем не против такого подхода: http://cocktail.ideablade.com/composing-view-models/ Вот то, что я писал выше Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Вместо ContentControl тут могли бы быть UserControl. Код: xml 1. 2. 3. 4. 5. 6. 7. 8.
После множества изысканий мы остановились на таком подходе для реализации "композитности". А есть разница? Я хотел обратить внимание на то, что удивился, что вы тут резко против композиции вью и вью моделей. Я понял, почему мне приходится обрабатывать дублирование данных и как тут сказали "подменять вью модель". У меня интерфейс такой, как на картинке. Я хочу создавать объект слева, жать на кнопку и заталкивать его в коллекцию потомков выбранного узла дерева справа. При этом хочу иметь возможность делать это много раз подряд - т. е. просто долбить кнопку добавления и копия одного и того же объекта будет добавляться в дерево. А у МСУ в его примере каждый новый объект создаётся в модальном окне, окно возвращает новый созданный объект главному окну и сервис вставляет этот новый объект в грид. А до грида - сохранят в репозитории (или где у него там данные хранятся). Т. е. он тоже делает два сохранения вместо одного - в репозиторий и в грид руками. Только он не копирует объект, т. к. ему не надо вставлять копию одного и того же много раз. По сути, мой и МСУ подход мало чем отличается - у него только сервис добавлен для уменьшения связей и нет моей функциональности копирования. МСУ, ты бы смог сделать так же, как у тебя, но без отдельного окна для нового объекта, а чтобы новый объект создавался рядом с гридом, типа как у меня рядом с деревом? Или это криминал? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 06:48 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Плюс в другом месте моего приложения тоже копирование применено. Мне надо было организовать подобие буфера обмена. У меня был конструктор объекта, который представлял буфер, и коллекция этих объектов. Надо было сделать так, чтобы при нажатии правой кнопкой мыши на любой объект из коллекции этот объект копировался в буфер (и, соответственно, в конструктор для его редактирования), а при нажатии на левую - из буфер заменял собой тот объект, на который нажали. Если то же дерево моё рассматривать, то мне надо было правой кнопкой мыши кликать на любом элементе дерева для копирования, и левой - для вставки. Поэтому я активно использовал подмену вью моделей. А копирование сделал через бинарную сериализацию. Причём как моделей, так и вью моделей. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 06:53 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Я хочу создавать объект слева, жать на кнопку и заталкивать его в коллекцию потомков выбранного узла дерева справа. При этом хочу иметь возможность делать это много раз подряд - т. е. просто долбить кнопку добавления и копия одного и того же объекта будет добавляться в дерево.И что это меняет? У меня есть контрол ItemsMultiSelector , правда примера по его применению нету, он используется в других проектах. Единственное отличие от твоего - там нет дерева, просто список. Но это так же ничего не меняет. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 06:59 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Алексей Кпропущено... Вместо ContentControl тут могли бы быть UserControl. Код: xml 1. 2. 3. 4. 5. 6. 7. 8.
После множества изысканий мы остановились на таком подходе для реализации "композитности". А есть разница?Не сильно. Просто показал альтернативное решение. user7320Я хотел обратить внимание на то, что удивился, что вы тут резко против композиции вью и вью моделей.Ещё раз. Я против смешивания в одних классах логики и структуры данных. Это нарушение SRP. Из-за этого тебе приходится описывать объёмную структуру данных в нескольких местах и заниматься бесполезным делегированием. А всё ради размещения логики в сеттерах свойств. Оно того не стоит. Ищи альтернативный способ размещения логики. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 07:13 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Я понял, почему мне приходится обрабатывать дублирование данных и как тут сказали "подменять вью модель". У меня интерфейс такой, как на картинке. Я хочу создавать объект слева, жать на кнопку и заталкивать его в коллекцию потомков выбранного узла дерева справа. При этом хочу иметь возможность делать это много раз подряд - т. е. просто долбить кнопку добавления и копия одного и того же объекта будет добавляться в дерево. А view model зачем для этого подменять. Просто после добавления создавай новый объект и знакомь VM левой панели с ним. Типа: Код: c# 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 08:58 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей КЯ против смешивания в одних классах логики и структуры данных. Это нарушение SRP. Это мне кажется ООП - когда в классе есть структура данных и некоторая логика, которая ее обслуживает. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 09:00 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperАлексей КЯ против смешивания в одних классах логики и структуры данных. Это нарушение SRP. Это мне кажется ООП - когда в классе есть структура данных и некоторая логика, которая ее обслуживает.Это особенность ООП в распределённых приложениях, коим является 2-х или 3-х звенка. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 09:23 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperuser7320Я понял, почему мне приходится обрабатывать дублирование данных и как тут сказали "подменять вью модель". У меня интерфейс такой, как на картинке. Я хочу создавать объект слева, жать на кнопку и заталкивать его в коллекцию потомков выбранного узла дерева справа. При этом хочу иметь возможность делать это много раз подряд - т. е. просто долбить кнопку добавления и копия одного и того же объекта будет добавляться в дерево. А view model зачем для этого подменять. Просто после добавления создавай новый объект и знакомь VM левой панели с ним. Типа: Код: c# 1. 2. 3. 4. 5.
При этом будут пустые поля левой панели. А мне надо, чтобы остались старые заполненные. Я пока самое простое, что придумал, это скопировать старую вью модель (с её моделью, естественно) и отдать её в коллекцию-дерево. Ну а старую оставить. Копирю через BinaryFormatter, предварительно расставив где надо атрибуты сериализации. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 10:31 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRКоллега, Вас уже два раза ткнули носом в Ваши косяки, но судя по всему Вы из тех людей, которые с пеной у рта готовы доказывать свою не правоту. А ты забавный. 1. Не понимаешь разницу между tier и layer, несешь околопоносный бред. 2. Не умеешь использовать view сервисы в mvvm. А теперь оказывается, что ты меня там куда-то ткнул? Самому-то не смешно? James Bond FRЕще раз - в чем смысл MVVM да и любого паттерна в принципе? Это уже другой вопрос. Я заметил, ты как еврей скачешь с одной темы не другую, пытаешься замести следы собственных сливов. Доколе? James Bond FRИдея MVVM да и WPF(Silverlight) в целом - дизайнер рисует UI, прогер кодит. В итоге дизайнер биндит контролы на сущности и все работает. С этим надеюсь тоже согласны? Что произойдет если дизайнер изменит имя employeesGrid на MyEmployeesGrid? Правильно! Ваш метод отвалится! Какие к черту "UI сервисы"? Что это за бред вообще? Хотя я конечно прекрасно понимаю что это - тупой соскок, попытка скрыть непригодность MVVM в чистом виде, который не жизнеспособен о чем я говорил выше. На мой взгляд это очевидные вещи, которые Вы не желаете признавть из-за своих амбиций или по другим не известным мне причинам. Я тебе не буду распинаться и доказывать нужность MVVM в XAML. Когда дорастешь до этого, сам поймешь. Я лишь окунаю тебя в то, в чем ты полный ноль. А это видно издалека. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 10:42 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320По сути, мой и МСУ подход мало чем отличается - у него только сервис добавлен для уменьшения связей и нет моей функциональности копирования. Правильно. Суть сервиса как-раз убрать эту зависимость. И логики в нём должно быть по минимуму. В идеале лучше стараться без него обойтись. user7320МСУ, ты бы смог сделать так же, как у тебя, но без отдельного окна для нового объекта, а чтобы новый объект создавался рядом с гридом, типа как у меня рядом с деревом? Или это криминал? Так это без сервиса всё делается. Байдинг на правильную вью модель, ICommand наполняет коллекцию, всё это отображается во вью. Детский сад. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 10:47 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей КИз-за этого тебе приходится описывать объёмную структуру данных в нескольких местах и заниматься бесполезным делегированием. А всё ради размещения логики в сеттерах свойств. Оно того не стоит. Ищи альтернативный способ размещения логики. Ну почему только в свойствах. Сейчас у меня это в командах. Я заметил, что не использую Children_CollectionChanged в своей ObservableCollection Children. Попробую логику изменения модели поместить туда. Т. е. в команде будет меняться вью модель дерева - потомок добавляться в Children, а в событии CollectionChanged будет обновляться модель... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 11:02 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320При этом будут пустые поля левой панели. То есть после добавления надо редактировать новый айтем, но являющийся копией только то добавленного. Код: c# 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 11:09 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
мсущкоJames Bond FRКоллега, Вас уже два раза ткнули носом в Ваши косяки, но судя по всему Вы из тех людей, которые с пеной у рта готовы доказывать свою не правоту. А ты забавный. 1. Не понимаешь разницу между tier и layer, несешь околопоносный бред. 2. Не умеешь использовать view сервисы в mvvm. А теперь оказывается, что ты меня там куда-то ткнул? Самому-то не смешно? James Bond FRЕще раз - в чем смысл MVVM да и любого паттерна в принципе? Это уже другой вопрос. Я заметил, ты как еврей скачешь с одной темы не другую, пытаешься замести следы собственных сливов. Доколе? James Bond FRИдея MVVM да и WPF(Silverlight) в целом - дизайнер рисует UI, прогер кодит. В итоге дизайнер биндит контролы на сущности и все работает. С этим надеюсь тоже согласны? Что произойдет если дизайнер изменит имя employeesGrid на MyEmployeesGrid? Правильно! Ваш метод отвалится! Какие к черту "UI сервисы"? Что это за бред вообще? Хотя я конечно прекрасно понимаю что это - тупой соскок, попытка скрыть непригодность MVVM в чистом виде, который не жизнеспособен о чем я говорил выше. На мой взгляд это очевидные вещи, которые Вы не желаете признавть из-за своих амбиций или по другим не известным мне причинам. Я тебе не буду распинаться и доказывать нужность MVVM в XAML. Когда дорастешь до этого, сам поймешь. Я лишь окунаю тебя в то, в чем ты полный ноль. А это видно издалека. Очень жаль коллега, но Вы очередная форумная пустышка. За сим откланиваюсь, кому нужно тот все понял. Удачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 11:13 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей КЭто особенность ООП в распределённых приложениях, коим является 2-х или 3-х звенка. И на любом из них соответсвющая структура данных объединена в соответствующих объектах с соответсвующей логикой. Или вы имеете ввиду анемичную доменную модель . ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 11:14 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
James Bond FRмсущкопропущено... А ты забавный. 1. Не понимаешь разницу между tier и layer, несешь околопоносный бред. 2. Не умеешь использовать view сервисы в mvvm. А теперь оказывается, что ты меня там куда-то ткнул? Самому-то не смешно? пропущено... Это уже другой вопрос. Я заметил, ты как еврей скачешь с одной темы не другую, пытаешься замести следы собственных сливов. Доколе? пропущено... Я тебе не буду распинаться и доказывать нужность MVVM в XAML. Когда дорастешь до этого, сам поймешь. Я лишь окунаю тебя в то, в чем ты полный ноль. А это видно издалека. Очень жаль коллега, но Вы очередная форумная пустышка. За сим откланиваюсь, кому нужно тот все понял. Удачи. Очень забавно такое читать от ламера, который слой звеном называет. Иди учись лучше, клоун. Буквари я тебе дал, как прочтешь, тогда и приходи на форум программистов. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 11:37 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperuser7320При этом будут пустые поля левой панели. То есть после добавления надо редактировать новый айтем, но являющийся копией только то добавленного. Код: c# 1. 2. 3. 4.
Я так и делаю. Всё дело в Clone(). Ваши предложения по его реализации? Лично я в сериализацию - т. к. она почти наверняка понадобится и для других целей. До этого делал просто метод, копировавший все нужные поля и вызывавший рекурсивно подобные же методы из составляющих моделей. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 12:40 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperАлексей КЭто особенность ООП в распределённых приложениях, коим является 2-х или 3-х звенка. И на любом из них соответсвющая структура данных объединена в соответствующих объектах с соответсвующей логикой.Если не лень писать DTO, воевать с "N+1 запрос" и прочими прелестями, в том числе представленными в данном топике - я не против. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 14:30 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Алексей КИз-за этого тебе приходится описывать объёмную структуру данных в нескольких местах и заниматься бесполезным делегированием. А всё ради размещения логики в сеттерах свойств. Оно того не стоит. Ищи альтернативный способ размещения логики. Ну почему только в свойствах. Сейчас у меня это в командах.Тогда мы ходим по кругу . user7320Я заметил, что не использую Children_CollectionChanged в своей ObservableCollection Children. Попробую логику изменения модели поместить туда. Т. е. в команде будет меняться вью модель дерева - потомок добавляться в Children, а в событии CollectionChanged будет обновляться модель...Ну удачи... :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 14:36 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Как считаете, нормально? Код: c# 1. 2. 3. 4. 5. 6.
Определяет, стоит ли пустить пользователя дальше с неверными куками, или пока повременить. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 16:40 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
private убери. Там по дефолту private. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 16:57 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей К, если что, я продолжаю делать это . Вот, добавил возможность прощения нескольких несовпадающих куки в единицу времени - сценарий смены браузера пользователем (пришёл домой с работы и т. п.). Но не пропустит тех, кто с двух браузеров под одним аккаунтом одновременно работает - будет постоянно отправлять на перелогинивание. Кстати, там говорили, что де куки могут "испортиться", потеряться и пр. форс-мажор, поэтому де на куках такое основывать это не по-взрослому. Ну чего-то я не видел, чтобы на форумах или ещё где куки терялись - например, тут я без вылогинивания месяцами сижу. Короче, куки достаточно надёжная вещь. В крайнем случае юзер раз в месяц лишний раз перелогинится. У меня вообще сессия убивается через двое суток (по дефолту в MembershipProvider). Вобщем, я попробовал поработать с двух брузеров - мои сценарии отрабатываются как я и задумал. Чего может быть не так? Какие подводные камни? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 17:07 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кprivate убери. Там по дефолту private. Я привык ставить явно. И скобочки на однострочные if/else. Я постоянно всё забываю - все эти дефолтные соглашения (вот, недавно забыл, в чём разница между return ++i и return i++), поэтому мне удобнее, когда явно. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 17:08 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Алексей К, если что, я продолжаю делать это . Вот, добавил возможность прощения нескольких несовпадающих куки в единицу времени - сценарий смены браузера пользователем (пришёл домой с работы и т. п.). Но не пропустит тех, кто с двух браузеров под одним аккаунтом одновременно работает - будет постоянно отправлять на перелогинивание. Кстати, там говорили, что де куки могут "испортиться", потеряться и пр. форс-мажор, поэтому де на куках такое основывать это не по-взрослому. Ну чего-то я не видел, чтобы на форумах или ещё где куки терялись - например, тут я без вылогинивания месяцами сижу. Короче, куки достаточно надёжная вещь. В крайнем случае юзер раз в месяц лишний раз перелогинится. У меня вообще сессия убивается через двое суток (по дефолту в MembershipProvider). Вобщем, я попробовал поработать с двух брузеров - мои сценарии отрабатываются как я и задумал. Чего может быть не так? Какие подводные камни? Тока чёта мой фильтр разросся до 200 строк кода. Правда, там половина - комменты с описанием алгоритма и четверть - скобочки и сообщения для логов. Реально за одно обращение к фильтру строк 20 выполняется. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 17:13 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
И в Профайле 5 переменных для работы этого всего. Зато ни у кого такого нет! ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 17:13 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Зато ни у кого такого нет! )))Верю. :-) зы: я с Asp.Net мало знаком чтобы что-то советовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 17:16 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей Кuser7320Зато ни у кого такого нет! )))Верю. :-) зы: я с Asp.Net мало знаком чтобы что-то советовать. MVC же. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 17:18 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Я так и делаю. Я имел ввиду копирование только элементов модели а не ViewModel Всё дело в Clone(). Ваши предложения по его реализации? Лично я в сериализацию - т. к. она почти наверняка понадобится и для других целей. До этого делал просто метод, копировавший все нужные поля и вызывавший рекурсивно подобные же методы из составляющих моделей. Зависит от разных вещей . Если нет вложенности, то MemberwiseClone ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 20:57 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperuser7320Я так и делаю. Я имел ввиду копирование только элементов модели а не ViewModel Прошу прощения, я так и делаю на самом деле. Мой пример несколько отвлечённый. Вот мой реальный код: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
Здесь я 2 раза копирую только модель. Однако, вью модель всё равно подменяю новым экземпляром вью модели (со старой моделью, которую копирую) - см. строчку под комментарием "Refresh the UI.". Это я делаю потому, что если просто добавлять старую вью модель в дерево справа (см. скрин на предыдущей странице), то я просто создам кучу представлений в дереве и в редакторе слева, ссылающихся на одну вью модель. Т. е. если в редакторе изменю, например, имя, то оно поменяется во всех представлениях в дереве, отображающих эту вью модель. Мне же этого не надо. Поэтому вью модель в дереве (или в редаторе - где удобнее) надо подменить. WebSharper Зависит от разных вещей . Если нет вложенности, то MemberwiseClone Вложенности есть, и немало. Я эту тему тоже изучал. Пришёл к выводу, что либо делать на каждый класс свой метод копирования (который будет вызывать подобные же методы для всех сложных объектов-полей этого класса), либо сериализация. Причём сериализация от первого метода принципиально не отличается - всё равно придётся рыскать руками по классам и помечать, что сериализовать, а что нет. С сериализацией больше хлопот - кроме того, что нужно пометить, что сериализовать, надо пометить, что сериализовать НЕ НАДО. Плюс сериализуемый класс должен иметь конструктор по умолчанию и некоторые другие требования. В своём методе этого ничего не надо - просто копируешь те поля, что нужны. Зато после расстановки атрибутов сериализации получаешь готовую сериализацию в любой формат - в Дотнете есть кучка готовых сериализаторов. Есть ещё всякие извилистые подходы. Я, например, вот этот код не понял. Начал разбираться, запутался и забил. Пусть у него "в 3 раза быстрее", но с сериализацией мне зато понятнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 21:24 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
CurrentQuest - это как раз то, что отображается на скрине слева в виде редактора полей квеста. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 21:27 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320 Здесь я 2 раза копирую только модель. Зачем ее копировать два раза. Почему нельзя вторую VM создать ссылающуюся на ту же M? Как происходит изначальная инициализация VM для дерева. По идее должен быть какой-то код, который отображает М в VM почему она не может подписаться на события модели и автоматически создать VM для айтема при добавлении его в модель? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 09:56 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperuser7320 Здесь я 2 раза копирую только модель. Зачем ее копировать два раза. Почему нельзя вторую VM создать ссылающуюся на ту же M? Как происходит изначальная инициализация VM для дерева. По идее должен быть какой-то код, который отображает М в VM почему она не может подписаться на события модели и автоматически создать VM для айтема при добавлении его в модель? Да, действительно... Что-то я не подумал. Но всё равно, остаётся ДВЕ операции над моделью. А я хочу, чтобы была одна - добавил в ObservableCollection новую вью модель, и чтобы в модели тоже всё добавилось. Т. е. один раз изменил, и все другие изменения, зависящие от этого, автоматом применились. Попробую такое сделать с подпиской на событие CollectionChanged для ObservableCollection. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 10:28 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperПо идее должен быть какой-то код, который отображает М в VM почему она не может подписаться на события модели и автоматически создать VM для айтема при добавлении его в модель? Я думаю сделать наоборот - сначала меняется вью модель, а потом она меняет свою модель. У меня так для свойств простых сделано, которые просто "пробрасывают" свойства модели во вью. А для коллеции я что-то ступил и забыл сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 10:56 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
user7320Я думаю сделать наоборот - сначала меняется вью модель, а потом она меняет свою модель. Получается, то тот, кто меняет модель, должен знать что существует конкретный вид view для нее и если потребуется сделать какое-то другое изменение для модели (например появится метод который добавляет n айтемов сразу) ту надо будет туда добавлять код для всех вью, которые его отображают. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 11:12 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
WebSharperuser7320Я думаю сделать наоборот - сначала меняется вью модель, а потом она меняет свою модель. Получается, то тот, кто меняет модель, должен знать что существует конкретный вид view для нее и если потребуется сделать какое-то другое изменение для модели (например появится метод который добавляет n айтемов сразу) ту надо будет туда добавлять код для всех вью, которые его отображают. Да, вы правы. Тогда наоборот. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 13:11 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Алексей КВся эта prism-байда отталкивается от неверного утверждения, мол приложения на "голом" WPF плохо разделяются на модули и вообще так себе: Эта байда изначально заточена на модульность и слабую связанность. А вот твой подход, где все завязано на левых и самопальных контролах, кототые реализуют куцый интерфейс с частными случаями, полностью противоречит концепции WPF, где есть все возможности отделить интерфейс от логики. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2014, 18:13 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Я вот не понял, чего МСУ так против иерархических VM и V? У меня вот такой интерфейс, как на картинке. Каждый красный прямоугольник - VM и соответствующая ему V. Самая главная вью модель - окно. Внутри контент презентеры, которые либо сразу внутри себя разметку имеют, либо через дата темплиты ссылаются на другие представления. Эти другие представления, в свою очередь, у меня выглядят как юзер контролы с разметкой. Ну и последовательный байндинг от главного окна до самого вложенного красного прямоугольника. Кнопочка с вопросиком - описание параметра. Описание хранится в модели в виде атрибута, а во вью модели вытаскивается в свойство, которое и привязывается. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2014, 17:04 |
|
Проблемы с иерархическими моделями представлений
|
|||
---|---|---|---|
#18+
Чёт, похоже, в этом разделе один я толкусь. Остальные все на джаваскрипт ушли? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2014, 17:07 |
|
|
start [/forum/topic.php?all=1&fid=21&tid=1441125]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
132ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
98ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 283ms |
0 / 0 |