Silverlight / MVVM Design: какая у меня модель и где поставить логику?

Question

Я разветвлен из потока При использовании шаблона MVVM должен ли код, относящийся к изменениям свойств, идти в установщик или событие?

Мое понимание шаблона MVVM в порядке с View идетали ViewModel ...

А как насчет модели?Будет ли это техническая объектная модель (сгенерированные классы EntityFramework SelfTracking, а затем расположенные за веб-службами, затем со ВСЕЙ бизнес-логикой на сервере) или логическая модель приложения (которую мы воссоздаем на клиенте Silverlight на основе классов сущностейКонечно, спасибо компоновщику проекта PRISM, он будет представлять ориентированные на GUI операции с большей доступной бизнес-логикой и инкапсулирует грязные технические вещи для доступа к WS для распространения изменений на сущностях в базе данных)?

(PersonnalyЯ думаю о втором)

В нашем проекте Silverlight / WCF (не RIA) мы управляем документами.У нас есть представления для отображения этих документов (например, InboxView.xaml), который придерживается файла InboxViewModel.cs, содержащего список документов для отображения.ListBox в InboxView - это DataBound для свойства DocumentList ObservableCollection в InboxViewModel.Но список ItemTemplate представляет собой DataBound для DocumentViewModel.cs, который инкапсулирует сущность, сгенерированную классом Document.cs.

Дело в том, что эта DocumentViewModel фактически используется другими представлениями ... (частично для меня, совсем нетесли MVVM предусматривает биекцию между Views и ViewModels? но это не моя точка зрения ...).

По моему скромному мнению, я бы предпочел иметь DocumentModel.cs вместо DocumentViewModel.cs, которыйможет совместно использоваться несколькими ViewModel (InboxViewModel, EditDocumentViewModel ...) и инкапсулирует вызовы WS для запуска бизнес-операций на стороне сервера с измененными объектами на стороне клиента.Затем мы должны иметь прикладную логическую модель или модель, ориентированную на графический интерфейс ( M -V-VM), в дополнение (и ниже, по слоям) к моделям представления (MV- VM )) и виды (M- V -VM).Все на стороне Silverlight.

Но тогда 2 вопроса:

1 - Если бы я сохранил мое скромное мнение, было бы нормально, чтобы DataBind ItemTemplate напрямую связывался с объектами Model?Поскольку ни одно из представлений не связано напрямую с DocumentModel, но связано со свойством в InboxViewModel (например), которое является объектом DocumentModel?

2 - В целом, что будет частью реализованной бизнес-логикина стороне сервера и на стороне клиента?Поскольку сервер предназначен для предоставления WS другим (вымышленным будущим или будущим fictionnal: p) приложениям, действительно ли мы хотим поместить всю первую бизнес-логику приложения на сервер или предоставлять только атомарные операции через WS и разрешать всем приложениямвместо этого реализовать свою правильную логику?

Мой технический руководитель постоянно наводняет меня ссылками, но это / он не дает мне никакого ответа, и более того, я просто пытаюсь думать здесь самостоятельно.

Спасибо всем вам, ребята ... Ура

Answer 1

Я думаю, что вы затрагиваете аспекты MVVM, в которых А) просят больше всего вопросов и Б) имеют наименьшее количество консенсуса.

Шаблон подразумевает три слоя: модель - это данные,View - это экран, а ViewModel находится между ними.Я начинаю думать, что это неточно или, по крайней мере, не оптимально.От данных к экрану, вот к чему я стремлюсь:

A) Сервисный уровень: этот код может быть реальным сервисом или оболочкой для вызовов ADO.NET.Какой бы ни была разновидность, его задача - взаимодействовать с физическим источником данныхЭто делается с использованием сущностей (не обязательно классов EF, только классов, представляющих базу данных).

B) Слой сущности: это классы, полученные на уровне службы.Все взаимодействие с физическим источником данных и из него происходит через эти классы сущностей.

C) Уровень модели данных: эти классы обертывают / управляют слоем сущности.В частности, они реализуют INotifyPropertyChanged, чтобы их можно было использовать позже в представлении, а также предоставляют методы и свойства для доступа к слою сущности.Эта абстракция позволяет изменять и обновлять слой Entity, не оказывая негативного влияния на ViewModel или View.

D) Уровень ViewModel: класс ViewModel, который также реализует INotifyPropertyChanged, управляет взаимодействием между классами View и Data Model.,Команды и специфическое визуальное форматирование свойства (скажем, объединение FirstName и LastName в свойство FullName) происходят на этом уровне.ViewModel может дополнительно абстрагировать класс Data Model, но на этом этапе в этом нет необходимости.

E) Слой вида: окончательный вид (Window, Page или UserControl).Мое жесткое и быстрое правило - поддерживать отношения 1 ViewModel для View (и наоборот).

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

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