Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
i seeDenis Gladkikhi, давайте не будем засорять "стенгазету", если действительно интересно про это поговорить напишите мне email и мы это обсудим ;)Денис, давайте уж здесь, зачем переводить в приват интересное обсуждение. Мне просто сложно продолжать эту тему тут, я не вижу вопросов, а вижу мнения. Потому и говорю, если интересно со мной поговорить на эту тему, то лучше в приват. Давайте переведем обсуждение немного в другое русло, с конкретными вопросами и ответами. В данном треде реально сложно следить за ветвью обсуждения. Я не могу понять, например, этого предложения "View(если я правильно понимаю, тяжело воспринимать русские аналоги, которых не существует за отсутствием литературы) в MVVM логики не имеет." Как не имеет? Какой логики? View это часть паттерна. iавториспользовать другое связывание данных, что под этим подразумевается совершенно непонятно я не понимаю откуда вырван контекст и что здесь обсуждается. iсовершенно не обязательно, если Model - отдельное свойство в ViewModel я говорил, что не принимаю эту реализацию, она ужасна. может быть в отдельных проектах, и то вряд ли. iстатья Фаулера, на мой вгзляд, совершенно не к месту. Xaml позволяет иметь в таких случаях два отдельных MVVM без всякой взаимосвязи, что гораздо проще и внятней. Здесь я тоже не понимаю связи этого предложения с моим высказыванием. Причем тут то, что XAML может иметь два отдельных MVVM, я говорил именно про разделения функциональности для PresentationModel и Presenter. В случае ViewModel вся функциональность падает на один класс ViewModel. Если два класса ViewModel то по два класса PresentationModel и Presenter должно быть. iВ таком случае мы будем иметь только нарушение принципов. Обычно в MVVM Моdel отвечает за валидацию, а VM за логику. Это и делает их более простыми и сфокусированными. Нет, это неверное толкование паттерна. ViewModel отвечает за связывание View и Model, но никак не за логику, и что подразумевается под логикой? iVM совершенно не зависит от VIew, сооветственно последних может быть сколько угодно Может быть в некоторых случаях, а так только на словах она не зависит. "Логически" она зависит на 90%. i see я хочу перевести это в приват, чтобы нормально разобраться в вопросе, который здесь возник. Так мы разведем здесь разговор на несколько страниц ни к чему не приводящих. В привате я постараюсь понять мнение собеседника, и потом сделать вывод "отчет", который увидят все. Я могу признать что я где-то не прав, потому с удовольствием это обсужу, только в более "плановом" русле. Как хотите можно и тут все разобрать, только давайте как-то по пунктам, по темам, а не вырывая словосочетания из контекста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 00:49 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis Gladkikh i see я хочу перевести это в приват, чтобы нормально разобраться в вопросе, который здесь возник....Как вам будет удобнее, Денис, мнение MVP для нас важно :) Но по результатам разбора полётов всё же прошу вас отписаться тут, если не затруднит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 00:53 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis Gladkikh i see я хочу перевести это в приват, чтобы нормально разобраться в вопросе, который здесь возник. Так мы разведем здесь разговор на несколько страниц ни к чему не приводящих. В привате я постараюсь понять мнение собеседника, и потом сделать вывод "отчет", который увидят все. i, ты же SeVa, ты же Silverlight, ты же "..." - (наш тебе наказ) мы, посетители энтого хворума, призываем тебя - будь с энтим парнем "Denis Gladkikh" - компетентен, комплиментарен, контактуарен, т.е., будь три "К"!!! (мы полагаемся на тебя) - и да подможет тебе Silverlight! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 02:38 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis GladkikhПравильно ли я понимаю, что вы говорите о том, чтобы осуществлять байдинг сразу к моделям, которые генерирует EF/Linq-To-SQL/WCFServices (нужное подчеркнуть), а Presenter/ViewModel должен просто тупо возвращать этот объект? Сразу скажу, что подход просто нереально ужасный, разрабатывая так руководствуются только ленью. По вашему принципу View это тоже wrapper над Моделью.Процитировал, чтобы освежить контекст. :-) Сомнительно. Как говорилось выше, если модель довольно объёмна - будет уходить масса времени на "тупой" мэппинг значений свойств. Denis GladkikhПроблемы будут разные. Сложнее поддерживать конструкцию, иногда не всегда можно будет осуществить байдинг именно на свойство модели, потому логика будет расплываться, что где-то будет осуществляться байдинг на модель, а где-то на свойство ViewModel.Непонятно, логика чего будет расплываться? Логика биндингов? А "конструкцию" поддерживать будет проще. Меньше изменений нужно будет вносить при изменении модели, одним слоем будет меньше. А все возникающие сложности решаются дописыванием в partial class модели. Denis GladkikhЕще стандартный вариант. Есть список и есть контрол для редактирования сущности. Пользователь начинает редактировать сущность, а потом нажимает отмена (вместо сохранить), а в нашу модель уже записались все данные. Более того, когда пользователь начинает редактировать, то он уже видит изменения и в списке, что не очень-то хорошо. Получается, в таких случаях нужно делать копию объекта, а потом уметь обновлять основной объект из копии. Либо при отмене постоянно перегружать коллекцию.А в любом случае придётся делать запрос к модели после сохранения записи, чтобы получить значения, вычисляемые в сервисах модели. И не "обновлять основной объект", а "заменить основной объект вновь полученным". И проблемы тут нет. Всё это легко выносится в базовые классы и в прикладном коде не присутствует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 06:43 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis GladkikhЯ не могу понять, например, этого предложения "View(если я правильно понимаю, тяжело воспринимать русские аналоги, которых не существует за отсутствием литературы) в MVVM логики не имеет." Как не имеет? Какой логики? View это часть паттерна. Всё правильно, в представлении нет логики, какие тут могут быть еще вопросы, Дениска? :) Denis Gladkikhiсовершенно не обязательно, если Model - отдельное свойство в ViewModel я говорил, что не принимаю эту реализацию, она ужасна. может быть в отдельных проектах, и то вряд ли. В чем Вы видите подвох, если модель будет опубликована во вьюмодели в качестве проперти? Что ужасного? )) Denis Gladkikhя говорил именно про разделения функциональности для PresentationModel и Presenter. В случае ViewModel вся функциональность падает на один класс ViewModel. Если два класса ViewModel то по два класса PresentationModel и Presenter должно быть. Мне единственное, что не устраивает в MVVM - это описание работы модели во вьюмодели (в том чисте и событийная часть). Лишаемся замечательного Code Behind, пляшем с бубнами в классе-описателе для решения банального поведения гуя. Маразм. MVVM несъедобен в принципе. Denis GladkikhНет, это неверное толкование паттерна. ViewModel отвечает за связывание View и Model, но никак не за логику, и что подразумевается под логикой? +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 08:35 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
МСУМне единственное, что не устраивает в MVVM - это описание работы модели и представления во вьюмодели (в том чисте и событийная часть). P.S. Да чтож такое, руки кривят с утра :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 08:38 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
МСУDenis GladkikhЯ не могу понять, например, этого предложения "View(если я правильно понимаю, тяжело воспринимать русские аналоги, которых не существует за отсутствием литературы) в MVVM логики не имеет." Как не имеет? Какой логики? View это часть паттерна. Всё правильно, в представлении нет логики, какие тут могут быть еще вопросы, Дениска? :) Denis Gladkikhпропущено... я говорил, что не принимаю эту реализацию, она ужасна. может быть в отдельных проектах, и то вряд ли. В чем Вы видите подвох, если модель будет опубликована во вьюмодели в качестве проперти? Что ужасного? )) Denis Gladkikhя говорил именно про разделения функциональности для PresentationModel и Presenter. В случае ViewModel вся функциональность падает на один класс ViewModel. Если два класса ViewModel то по два класса PresentationModel и Presenter должно быть. Мне единственное, что не устраивает в MVVM - это описание работы модели во вьюмодели (в том чисте и событийная часть). Лишаемся замечательного Code Behind, пляшем с бубнами в классе-описателе для решения банального поведения гуя. Маразм. MVVM несъедобен в принципе. Denis GladkikhНет, это неверное толкование паттерна. ViewModel отвечает за связывание View и Model, но никак не за логику, и что подразумевается под логикой? +1 В кои-то веки у нас с MCУ совпали мнения аж по двум вопросам!!! В последнем ребята глубоко ошибаются. VM содержит команды, а они во всех паттернах реализуют необходимую логику. MVP всем хорош, за исключением одной немаловажной детали - наличием View в Presenter'e. Это значительно все усложняет и делает неверным еще одно высказывание: "Presenter может использоваться для нескольких представлений". В 90% две основные задачи: показ списков; редактирование выбранной записи. С замечательными свойствами биндинга в WPF\SL это спокойно можно делать без ссылок на View в VM. C нелинейной навигацией, которая имеет больший функционал, чем одно диалоговое окно, можно обойтись без ChildView. Отдельное свойство для Моdel широко используется в подавляющем большинстве фреймворков, тк граф объектов может быть очень развесистым(root->child->grandchild, etc) Делать его плоским - пустая трата времени и сил.Если вводить отдельные Presenter'ы для каждого объекта, то зачем тогда вообще нужна Моdel. Помимо этого в 90% можно обойтись без их явного создания, используя только их базовые классы. У MVVM один недостаток - он перегружен. Все остальные аргументы неубедительны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 09:56 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
iЕсли вводить отдельные Presenter'ы для каждого объекта, то зачем тогда вообще нужна Моdel. Помимо этого в 90% можно обойтись без их явного создания, используя только их базовые классы. Модель нужна для байдинга, он очень вскусен. Ты, видимо, хотел сказать - вьюмодель. Да, я согласен, что можно без вьюмодели. Презентационного (Code Behind, по asp.net'овски) слоя вполне хватит. Но дело в том, что использование вьюмодели можно "гибче" адаптировать под твои любимые тесты (только ее логика, без событийной части). Событийную часть нефик тестить - для этого можно натравить робота. Во-вторых, с помощью вьюмодели можно гораздо с меньшими бубнами портировать проложение на другую платформу. Вызовы же юзать в соответствии со спецификой той платформы. А вот с MVVM ты не перенесешь вызовы со своими командами, ибо они не будут работать на том же ASP.NET или WinForms. Это, кстати, опять один из огромных минусов MVVM. Вызовы должны быть специфичны в рамках используемой платформы. iУ MVVM один недостаток - он перегружен. Все остальные аргументы неубедительны Выше я озвучил еще недостаток. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 10:11 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
МСУiЕсли вводить отдельные Presenter'ы для каждого объекта, то зачем тогда вообще нужна Моdel. Помимо этого в 90% можно обойтись без их явного создания, используя только их базовые классы. Модель нужна для байдинга, он очень вскусен. Ты, видимо, хотел сказать - вьюмодель. Да, я согласен, что можно без вьюмодели. Презентационного (Code Behind, по asp.net'овски) слоя вполне хватит. Но дело в том, что использование вьюмодели можно "гибче" адаптировать под твои любимые тесты (только ее логика, без событийной части). Событийную часть нефик тестить - для этого можно натравить робота. Во-вторых, с помощью вьюмодели можно гораздо с меньшими бубнами портировать проложение на другую платформу. Вызовы же юзать в соответствии со спецификой той платформы. А вот с MVVM ты не перенесешь вызовы со своими командами, ибо они не будут работать на том же ASP.NET или WinForms. Это, кстати, опять один из огромных минусов MVVM. Вызовы должны быть специфичны в рамках используемой платформы. iУ MVVM один недостаток - он перегружен. Все остальные аргументы неубедительны Выше я озвучил еще недостаток. Нет, MCУ, ты меня не правильно понял. VM обязательно нужна для агрегации данных. Вызовы конанд специфичны, а реализация логики в них спокойно может переноситься ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 10:20 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
iНет, MCУ, ты меня не правильно понял. VM обязательно нужна для агрегации данных. Не в коей мере это не так. VM - это тупо абстракция представления. Приложения WPF с шаблоном проектирования модель-представление-модель представления MVVMОднако в этой статье я буду называть шаблон аббревиатурой MVVM, а абстракцию представления — моделью представления. В сообществах WPF и Silverlight такая терминология значительно более распространена. И предлагаю не путаться в определениях. А то у нас в дискуссии каша какая-то. iВызовы конанд специфичны, а реализация логики в них спокойно может переноситься Сомнительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 10:31 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
МСУiНет, MCУ, ты меня не правильно понял. VM обязательно нужна для агрегации данных. Не в коей мере это не так. VM - это тупо абстракция представления. Приложения WPF с шаблоном проектирования модель-представление-модель представления MVVMОднако в этой статье я буду называть шаблон аббревиатурой MVVM, а абстракцию представления — моделью представления. В сообществах WPF и Silverlight такая терминология значительно более распространена. И предлагаю не путаться в определениях. А то у нас в дискуссии каша какая-то. iВызовы конанд специфичны, а реализация логики в них спокойно может переноситься Сомнительно. Чтобы не путаться самый простой вариант - не вводить русских определений. Лично я, их совершенно не воспринимаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 10:53 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
MVP валят! ну ничего святого не осталось! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 10:54 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
iЧтобы не путаться самый простой вариант - не вводить русских определений. Лично я, их совершенно не воспринимаю. Ок, вот описываю "мой" паттерн (сместь MVVM и MVP(C)): НазваниеОписание View CategoryList.xaml ViewModel CategoryListModel.cs Model кодогенерация враппера WCF сервиса (Service References)Code BehindCategoryList.xaml.cs View Код: plaintext 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. ViewModel Код: plaintext 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. ModelНу, тут без вопросов Code Behind Код: plaintext 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. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. P.S. И тестировать легко, и переносить на другие платформы легко, никакого прибивания гвоздей к специфике событий (или команд). Всё по-рихтеро-фаулерски. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 11:06 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Кстати, по поводу утечек памяти. Где-то читал, что зверски текут ChildWindow. Ну и как на этом сыром SL писать софт? :) P.S. Вообще, сам XAML - сплошной мемори лик... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 11:30 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Алексей К...будет уходить масса времени на "тупой" мэппинг значений свойств. ... "конструкцию" поддерживать будет проще. Меньше изменений нужно будет вносить при изменении модели, одним слоем будет меньше. А все возникающие сложности решаются дописыванием в partial class модели. угу, так и поступаю - где вьюмодель на 90% "тупой" мэппинг значений свойств модели - дописываю недостающие свойства вьюмодели в "собачий хвост" partial class (модели), а если вьюмодель объединяет несколько моделей - wrapper (соотв. биндинг на вьюмодель.модель.свойство) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 12:22 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Мда, дискуссия получила другой оборот. Безумно рад, что этот вопрос даже, такое ощущение, примирил i и МСУ в некоторых вопросах. Алексей КСомнительно. Как говорилось выше, если модель довольно объёмна - будет уходить масса времени на "тупой" мэппинг значений свойств. У меня такой подход: я практически отказываюсь от кодогенерации, все сервисы и объекты описываю сам, там у меня Dto объекты, которые несут только в себе полезную для контекста информацию (максимальная экономия трафика). Для осуществления байдинга, конечно, нет смысла для каждого объекта осуществлять PresentationModel, но это для тех случаев, когда у нас идет readonly binding, то есть OneWay. В случае редактирования я придерживаюсь создания полей именно в PresentationModel и байдинга на них. В результате бизнес объекты не перегружены, в них нет всяческих реализаций INotifyPropertyChanged интерфейсов (которые по большому счету не нужны нигде кроме View, если это не объекты EF/WCF RIA и т.п.). Так же в PresentationModel описывается валидация, которая наиболее полная: правила, сообщения. Очевидно, что часто приходится дублировать некоторые валидационные правила, во-первых на стороне сервера (сервисы), во-вторых в БД (уникальные ключи и т.п.). Но основная валидация это все таки на стороне клиента (в SL приложении), вся остальная это защита от взлома. Алексей К Непонятно, логика чего будет расплываться? Логика биндингов? А "конструкцию" поддерживать будет проще. Меньше изменений нужно будет вносить при изменении модели, одним слоем будет меньше. А все возникающие сложности решаются дописыванием в partial class модели. В моем случае может быть больше кода, зато мне кажется более чище выглядит код, и ясно где что искать. Скажем так, я быстро печатаю :) Алексей КА в любом случае придётся делать запрос к модели после сохранения записи, чтобы получить значения, вычисляемые в сервисах модели. И не "обновлять основной объект", а "заменить основной объект вновь полученным". И проблемы тут нет. Всё это легко выносится в базовые классы и в прикладном коде не присутствует. Может быть, один раз участвовал в таком подходе, писали на WPF + LinqToSQL, мне откровенно не понравилось. Слишком много путаницы. Пытались и с длинными сессиями и с короткими работать. iVM содержит команды, а они во всех паттернах реализуют необходимую логику. VM по классическому определению должна осуществлять связь между Model и View. Вся логика (как я понимаю это бизнес логика) должна быть в Model! Model - это не только классы-объекты, которые генерируются EF/WCF или еще чем, а это вся бизнес логика, и даже сервисы и т.п. iMVP всем хорош, за исключением одной немаловажной детали - наличием View в Presenter'e. View в Presenter не обязательна. МСУ продемонстрировал как раз пример MVP без использования View в Presenter. Но вот иногда ее бывает полезно иметь, например, для тех же BusyIndicator, ChildWindow и т.п., чтобы сделать нечто вроде IDisposable интерфейса для представлений (и то зависит от реализации Presenter-First или View-First, какая инициализация происходит первая контроллера или представления, и соответственно кто умирает первым). iУ MVVM один недостаток - он перегружен. Все остальные аргументы неубедительны Именно, потому я и говорю про разделение VM на Presenter и PresentationModel. Presenter несет в себе связь с сервисами, PresentationModel связь с представлением, как-то так. Причем так же можно PresentationModel использовать для нескольких Presenter и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 12:27 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis GladkikhУ меня такой подход: я практически отказываюсь от кодогенерации, все сервисы и объекты описываю сам, там у меня Dto объекты, которые несут только в себе полезную для контекста информацию (максимальная экономия трафика). Для осуществления байдинга, конечно, нет смысла для каждого объекта осуществлять PresentationModel, но это для тех случаев, когда у нас идет readonly binding, то есть OneWay. В случае редактирования я придерживаюсь создания полей именно в PresentationModel и байдинга на них. В результате бизнес объекты не перегружены, в них нет всяческих реализаций INotifyPropertyChanged интерфейсов (которые по большому счету не нужны нигде кроме View, если это не объекты EF/WCF RIA и т.п.). Это неплохо решается с помощью partial class. А с серверной стороны в "собачий хвост" вполне уместно запихнуть, например, код ORM. Общими (для трафика) остаются лишь свойства DataMember (ну и необходимые для обеих сторон методы). В случае SL такой подход особенно оправдан, т.к. приходится "шарить" исходники. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 12:55 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis GladkikhУ меня такой подход: я практически отказываюсь от кодогенерации А смысл? Рутина ведь. Вообще, лично я не очень уважаю DTO подходы, ибо рутина - извечный враг. К оффтопу заметить, что ну всем нравится хибернейт, но реально минус в том, что руками нужно писать классы, маппинг и DAL. В отличие от L2S/EF, где теме и маппинги генерятся, и DAL какой-никакой генерится при контексте. А вот EF-ский DTO ну никак не радует. Denis GladkikhВ результате бизнес объекты не перегружены, в них нет всяческих реализаций INotifyPropertyChanged интерфейсов (которые по большому счету не нужны нигде кроме View, если это не объекты EF/WCF RIA и т.п.). Не понял, что Вы называете бизнес-объектами - сущности модели или вью-модели? Во-вторых, что значит не нужны INotifyPropertyChanged, то есть как это (если речь о вьюмодели)? В-третьих (если речь о модели-таки), кодогенераторы сами по-дефолту генерят пропертя с INotifyPropertyChanged. Не понял Вас. Вот видите, если отказываться от кодогенерации - многое теряешь. А руками это всё писать - рутинно. Denis GladkikhМожет быть, один раз участвовал в таком подходе, писали на WPF + LinqToSQL, мне откровенно не понравилось. Слишком много путаницы. Пытались и с длинными сессиями и с короткими работать. О каких сессиях идет речь? Во-вторых, нет информации о транспорте данных - напрямую к SQL серверу или SOA? МСУ продемонстрировал как раз пример MVP без использования View в Presenter. Но вот иногда ее бывает полезно иметь, например, для тех же BusyIndicator, ChildWindow и т.п., чтобы сделать нечто вроде IDisposable интерфейса для представлений[/quote]. Вот Вам реализация ChildWindow на таком же паттерне, о котором я говорил: CategoryPicker.xaml Код: plaintext 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. CategoryPicker.xaml.cs Код: plaintext 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. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. CategoryPickerModel.cs Код: plaintext 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. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. Собственно вызов: Код: plaintext Код: plaintext 1. 2. 3. 4. 5. 6. 7. И никаких противоречий. Плюс, опять же, в том, что я с гораздо меньшими граблями портировать код на другую платформу, даже не ориентированную на XAML. Вот оно чё, Дениска. Denis GladkikhiУ MVVM один недостаток - он перегружен. Все остальные аргументы неубедительны Именно, потому я и говорю про разделение VM на Presenter и PresentationModel. Presenter несет в себе связь с сервисами, PresentationModel связь с представлением, как-то так. Причем так же можно PresentationModel использовать для нескольких Presenter и т.п. +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 12:57 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
offПорадовала оценка сроков задачи :) http://outcoldman.ru/ru/blog/show/257 ДенискаНедавно менеджеры попросили добавить сортировку. Я прикинул, что в простом случае, когда все элементы подгружаются за раз, сделать сортировку очень просто, нужно всего добавить CanUserSort к колонкам и все. Задачу оценили в час (вместе с тестированием и развертыванием). P.S. Без обид )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 13:08 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis GladkikhУ меня такой подход: я практически отказываюсь от кодогенерации, все сервисы и объекты описываю сам, там у меня Dto объекты, которые несут только в себе полезную для контекста информацию (максимальная экономия трафика).Это уже как модель будет спроектирована. ПМСМ, нужно стремиться к тому, чтобы DTO соответствовали сущностям модели. Тогда необходимость в дополнительных DTO отпадёт и траффик будет минимальным. Ну или будет достигнут разумный компромис между созданием DTO и использованием существующих классов модели. Denis GladkikhДля осуществления байдинга, конечно, нет смысла для каждого объекта осуществлять PresentationModel, но это для тех случаев, когда у нас идет readonly binding, то есть OneWay. В случае редактирования я придерживаюсь создания полей именно в PresentationModel и байдинга на них. В результате бизнес объекты не перегружены, в них нет всяческих реализаций INotifyPropertyChanged интерфейсов (которые по большому счету не нужны нигде кроме View, если это не объекты EF/WCF RIA и т.п.).Учитывая объёмы данных, обрабатываемых на клиенте, "перегруженность" в виде INotifyPropertyChanged вряд ли на что-либо повлияет. Denis GladkikhТак же в PresentationModel описывается валидация, которая наиболее полная: правила, сообщения. Очевидно, что часто приходится дублировать некоторые валидационные правила, во-первых на стороне сервера (сервисы), во-вторых в БД (уникальные ключи и т.п.). Но основная валидация это все таки на стороне клиента (в SL приложении), вся остальная это защита от взлома.Я бы сказал наоборот. Основная логика валидации данных расположена в модели. Логика предварительной валидации в PresentationModel - это бантик для удобства пользователя, может в каких-то случаях для экономии траффика и уменьшения количества запросов на сервер. Denis GladkikhВ моем случае может быть больше кода, зато мне кажется более чище выглядит код, и ясно где что искать. Скажем так, я быстро печатаю :)"Овчинка выделки не стоит" (с) народное. :-) Denis GladkikhАлексей КА в любом случае придётся делать запрос к модели после сохранения записи, чтобы получить значения, вычисляемые в сервисах модели. И не "обновлять основной объект", а "заменить основной объект вновь полученным". И проблемы тут нет. Всё это легко выносится в базовые классы и в прикладном коде не присутствует. Может быть, один раз участвовал в таком подходе, писали на WPF + LinqToSQL, мне откровенно не понравилось. Слишком много путаницы. Пытались и с длинными сессиями и с короткими работать.Видимо, дело привычки. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 13:21 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
МСУА смысл? Рутина ведь. Вообще, лично я не очень уважаю DTO подходы, ибо рутина - извечный враг. К оффтопу заметить, что ну всем нравится хибернейт, но реально минус в том, что руками нужно писать классы, маппинг и DAL. В отличие от L2S/EF, где теме и маппинги генерятся, и DAL какой-никакой генерится при контексте. А вот EF-ский DTO ну никак не радует. А мне вот не нравятся кодогенераторы, на них сложно полагаться в сложных проектах. Люди используют EF/LinqToSQL и т.п. даже не подозревая как это все должно работать. Не думаю о сессиях, о транзакциях, о состояниях объектов и т.п. А вообще у nHibernate есть кодогенераторы, они не идут в комплекте. Да и самому просто написать. МСУНе понял, что Вы называете бизнес-объектами - сущности модели или вью-модели? Во-вторых, что значит не нужны INotifyPropertyChanged, то есть как это (если речь о вьюмодели)? В-третьих (если речь о модели-таки), кодогенераторы сами по-дефолту генерят пропертя с INotifyPropertyChanged. Не понял Вас. Вот видите, если отказываться от кодогенерации - многое теряешь. А руками это всё писать - рутинно. Приехали. Бизнес объект . Для меня никакой рутины в этом нет. Все зависит от проекта, где-то это хорошо работает, а где-то не очень. MVC сложнее WinForms, потому что там писать больше кода нужно, но зато на выходе получаются более качественные веб-проекты. Разве не так? МСУО каких сессиях идет речь? Во-вторых, нет информации о транспорте данных - напрямую к SQL серверу или SOA? Сессиях ORM. Есть понятие длинных и коротких сессиях. Зависит от того, как вы держите сессию, либо только за загрузку объектов, либо раз загрузили, оставили открытой, работают Lazy свойства и т.п. Соединение было напрямую с БД. МСУИ никаких противоречий. Плюс, опять же, в том, что я с гораздо меньшими граблями портировать код на другую платформу, даже не ориентированную на XAML. Вот оно чё, Дениска. Не понял к чему реализация ChildWindow мне. Про какие противоречия мы говорили? Как я понимаю вызов его делаете в codebehind другого окна. Ну что ж, это прелести Presenter. В случае ViewModel не все так просто. Но, это как раз один из случаев, почему я считаю MVP подход более практичным, меньше ограничений на реализацию. МСУ, если вас не затруднит, то не обращайтесь ко мне подобным образом, я все таки вам не приятель ;) МСУПорадовала оценка сроков задачи :) http://outcoldman.ru/ru/blog/show/257 Дениска Недавно менеджеры попросили добавить сортировку. Я прикинул, что в простом случае, когда все элементы подгружаются за раз, сделать сортировку очень просто, нужно всего добавить CanUserSort к колонкам и все. Задачу оценили в час (вместе с тестированием и развертыванием). P.S. Без обид )) По мне так хватит уже флудить. Если есть вопросы лично ко мне - то давайте заведем отдельную ветвь на этом форуме. Ну, реально, засрали уже этот тред, и как я понимаю данное происходит с любым тредом. А не нравится оценка задачи? Я не настаиваю ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 13:44 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Алексей КВидимо, дело привычки. :-) Я тоже так думаю. Сколько людей - столько мнений. Это же замечательно, что живут разные подходы к разработки ПО. Насколько я понимаю у людей приживается подход, который рассказывают как раз на MS мероприятиях по разработке приложений на SL/WPF, что ж классно, если он действительно работает. В моем случае мне не нравилось как он работал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 13:50 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
Denis GladkikhА мне вот не нравятся кодогенераторы, на них сложно полагаться в сложных проектах. Это как "полагаться"? Denis GladkikhЛюди используют EF/LinqToSQL и т.п. даже не подозревая как это все должно работать. Не думаю о сессиях, о транзакциях, о состояниях объектов и т.п. Ну так люди-то разные бывают. Есть и такие, которые подозревают "о сессиях, о транзакциях, о состояниях объектов и т.п.". Уж поверьте мне. Denis GladkikhА вообще у nHibernate есть кодогенераторы, они не идут в комплекте. Да и самому просто написать. Я бы не сказал, что "просто" написать. Не видел ни одного вменяемого маппинго-генератора. Слишком гибкий и сложный маппинг можно писать на хибере ручками. Denis GladkikhПриехали. Бизнес объект. Для меня никакой рутины в этом нет. Все зависит от проекта, где-то это хорошо работает, а где-то не очень. Ну так в бизнес-объекте по-дефолту генерятся INotifyPropertyChanged. В чем проблема-то? Реализация уже есть по-дефолту. Denis GladkikhMVC сложнее WinForms, потому что там писать больше кода нужно, но зато на выходе получаются более качественные веб-проекты. Разве не так? Вообще-то, странное сравнение: MVC и WinForms. Что сложнее, апельсин или корова? Denis GladkikhСессиях ORM. ORM - ORM'у рознь. В нормальных кругах это называют контекстом. В хибе это называют фабрикой сессий (ISessionFactory, типа глобального контекста), и сессией (ISession, типа локального контекста). А еще сессия бывает у студентов. Так что говорите конкретней. Denis GladkikhЕсть понятие длинных и коротких сессиях. Зависит от того, как вы держите сессию, либо только за загрузку объектов, либо раз загрузили, оставили открытой, работают Lazy свойства и т.п. Соединение было напрямую с БД. Опять сессия... ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 13:57 |
|
||
|
MVVM Framework. Кто какой использует?
|
|||
|---|---|---|---|
|
#18+
МСУНу так в бизнес-объекте по-дефолту генерятся INotifyPropertyChanged. В чем проблема-то? Реализация уже есть по-дефолту. Хватит уже топтаться на месте. Где генерятся по дефолту? Я вот классы пишу, у меня почему то не генерируются по дефолту реализации INotifyPropertyChanged, пишу с использованием nHibernate и тоже ничего не генерируется. Может быть в случае использования какого-то особого фреймворка генерируются по дефолту? А как думаете, этот фреймворк о котором вы говорите используется всеми разработчиками? МСУORM - ORM'у рознь. В нормальных кругах это называют контекстом. В хибе это называют фабрикой сессий (ISessionFactory, типа глобального контекста), и сессией (ISession, типа локального контекста). А еще сессия бывает у студентов. Так что говорите конкретней. Благо для меня нормальный круг - это родоначальник ORM'ов Nibernate, где всегда были определены понятия long-session и session-per-request-with-detached-objects http://docs.jboss.org/hibernate/core/3.3/reference/en/html/transactions.html. Это термин, а не имя класса. МСУВообще-то, странное сравнение: MVC и WinForms. Что сложнее, апельсин или корова? Ну если вы можете применить понятие "сложнее" к апельсину и корове, то я выберу ответ апельсин. МСУ, ладно, сейчас действительно все переходит больше в треп, а не дискуссию. Я нисколько нигде не указывал, что ваши подходы или идеи не верные. Заметьте, я только говорю о своих идея и подходах. Если они вам не подходят, это ваше право. Доказывать или опровергать мне, вроде, нет необходимости. Я, вроде, ответил на все разумные вопросы, которые были тут. В общем-то на форумы я хожу, чтобы что-то рекомендовать и помогать, а не для того чтобы потрепаться (видел вашу тему про Silverlight более чем на 30-40 страниц). Так что давайте закончим этот тред, а? Ну или по крайней мере я отсюда ухожу (с этого треда). Без обид. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 14:33 |
|
||
|
|

start [/forum/topic.php?fid=21&msg=37005797&tid=1442515]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
61ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
76ms |
get tp. blocked users: |
1ms |
| others: | 16ms |
| total: | 193ms |

| 0 / 0 |
