Составное руководство WPF: MVVM по сравнению с MVP
Итак, я немного поэкспериментировал и обнаружил следующее в Spark 2.4.0
def equal(a: Dataset[Row], b: Dataset[Row], expected: Boolean) = {
println(s"by logical hashCode ${a.queryExecution.logical.semanticHash == b.queryExecution.logical.semanticHash}")
println(s"by logical sameResult ${a.queryExecution.logical.sameResult(b.queryExecution.logical)}")
println(s"by optimized hashCode ${a.queryExecution.optimizedPlan.semanticHash == b.queryExecution.optimizedPlan.semanticHash}")
println(s"by optimized sameResult ${a.queryExecution.optimizedPlan.sameResult(b.queryExecution.optimizedPlan)}")
println(s"expected: $expected")
println("\n")
}
val a = spark.createDataset(Seq(1, 2)).filter($"value" > 1).filter($"value" > 1).toDF
val b = spark.createDataset(Seq(1, 2)).filter($"value" > 1).toDF
val c = spark.createDataset(Seq(2, 3)).filter($"value" > 1).toDF
val d = spark.createDataset(Seq(2, 3)).filter($"value" < 1).toDF
val e = spark.read.parquet("/test_1")
val f = spark.read.parquet("/test_1")
val g = spark.read.parquet("/test_2")
val h = spark.read.parquet("/test_1").filter($"value" < 1)
val i = spark.read.parquet("/test_1").filter($"value" > 1)
equal(a, b, true)
// by logical hashCode false
// by logical sameResult false
// by optimized hashCode true
// by optimized sameResult true
// expected: true
equal(b, c, false)
// by logical hashCode false
// by logical sameResult false
// by optimized hashCode false
// by optimized sameResult false
// expected: false
equal(c, d, false)
// by logical hashCode true
// by logical sameResult false
// by optimized hashCode false
// by optimized sameResult false
// expected: false
equal(e, f, true)
// by logical hashCode true
// by logical sameResult true
// by optimized hashCode true
// by optimized sameResult true
// expected: true
equal(e, g, false)
// by logical hashCode false
// by logical sameResult false
// by optimized hashCode false
// by optimized sameResult false
// expected: false
equal(h, i, false)
// by logical hashCode true
// by logical sameResult false
// by optimized hashCode true
// by optimized sameResult false
// expected: false
Так что, думаю, я хочу выбрать sameResults в оптимизированном плане.
4 ответа
Ad.3. It may seem that you repeat yourself by exposing Model in ViewModel, but what you really do is abstracting the Model, so that View knows only about this abstraction (View knows only about ViewModel).
This is because changes to Model shouldn't break the View. Also, your Model can be implemented as many different services that get data from different sources. In this case you wouldn't like View to know about all of them, so you create another abstraction - ViewModel.
Если докладчик знает интерфейс представления, вам нужно, чтобы все представления, используемые докладчиком, имели одинаковый интерфейс, или создать докладчика для каждого представления. С MVVM представление знает о viewModel, а viewModel знает о модели (но не наоборот). Это означает, что несколько представлений могут использовать виртуальную машину, а несколько виртуальных машин могут использовать модель.
Я не совсем уверен, что вы спрашиваете во втором пункте. Виртуальная машина не является представлением (или осведомлена о представлениях), и для меня DataTemplate определяет, как отображается объект. Я поместил свои DataTemplates в ResourceDictionary, который определенно принадлежит в представлении. Единственные кусочки WPF-содержимого в моем уровне VM - это команды.
Мне нужно немного больше информации, чтобы ответить на ваш 3-й вопрос. Возможно, он сам ответит, если немного углубиться в MVVM.
Помимо комментариев выше. Я хотел бы поделиться своим пониманием разницы.
Обычно в MVP у вас есть интерфейс View, например. IView, чтобы абстрагироваться от фактических представлений и связывать данные с этими фактическими представлениями. В MVVM вместо этого вы обычно используете DataContext фактического представления, например. пользовательский элемент управления XAML для привязки данных, аналогичный IView в MVP. Итак, предположим, неточно, привязка одинакова для обоих шаблонов.
Основное различие заключается в части Presenter и ViewModel. Модель представления сильно отличается от презентатора, который является мостом для обмена данными между пользовательским интерфейсом и моделью. На самом деле, как и означает его название, модель представления. Данные, представленные в ViewModel, в основном предназначены для пользовательского интерфейса. Итак, насколько я понимаю, в MVVM ViewModel - это абстракция представлений. Напротив, MVP в основном использует IView для абстрактных представлений. Так что обычно в MVVM меньше слоев, чем в MVP, и, следовательно, вы можете написать меньше кода для выполнения той же работы в MVVM:
MVVM: Модель - ViewModel (представляет фактические представления, т.е. UI) - Фактические представления
MVP: Модель - Presenter (мост для обмена данными между моделью и пользовательским интерфейсом) - IView (представляет фактические представления, т.е. пользовательский интерфейс) - Фактические представления
Преимущество MVVM над MVP в основном основано на следующих двух отличных функциях продуктов Microsoft:
Командование в WPF. В будущем это может быть доступно в Silverlight, хотя уже есть некоторые реализации, которых нет в среде выполнения Silverlight
DataContext в WPF и Silverlight.
Что касается № 3, многие люди будут использовать " Я хочу пометить каждый элемент в коллекции логическим значением, когда пользователь щелкает галочку рядом с этим элементом в представлении. Возможно, вам понадобится свойство IsSelected. Это поведение, которое Модель не должна обеспечивать.
Однако я вижу, откуда вы пришли ... Сначала у меня определенно была проблема с этим. Когда я в первый раз копирую и вставляю содержимое модели в свою модель просмотра, у меня перевернулся живот, но вам просто нужно смириться с тем фактом, что для того, чтобы ваше представление работало, ему понадобится этот дополнительный бит поведения, который модель не должна Предоставлю.
Независимо от того, насколько это не-DRY, принуждение ваших типов WCF или LINQ to SQL (или любого другого вашего любимого ORM) к реализации INotifyProperyChanged - еще хуже.
Возможно, вам понадобится свойство IsSelected. Это поведение, которое Модель не должна обеспечивать.Однако я вижу, откуда вы пришли ... Сначала у меня определенно была проблема с этим. Когда я в первый раз копирую и вставляю содержимое модели в свою модель просмотра, у меня перевернулось животе, но вам просто нужно смириться с тем фактом, что для работы вашего представления потребуется дополнительная часть поведения, которой модель не должна Предоставлю.
Независимо от того, насколько это не-DRY, принуждение ваших типов WCF или LINQ to SQL (или любого другого вашего любимого ORM) к реализации INotifyProperyChanged - еще хуже.
Возможно, вам понадобится свойство IsSelected. Это поведение, которое Модель не должна обеспечивать.Однако я вижу, откуда вы пришли ... Сначала у меня определенно была проблема с этим. Когда я в первый раз копирую и вставляю содержимое модели в свою модель просмотра, у меня перевернулся живот, но вам просто нужно смириться с тем фактом, что для того, чтобы ваше представление работало, ему понадобится этот дополнительный бит поведения, который модель не должна Предоставлю.
Независимо от того, насколько это не-DRY, принуждение ваших типов WCF или LINQ to SQL (или любого другого вашего любимого ORM) к реализации INotifyProperyChanged - еще хуже.
Когда я в первый раз копирую и вставляю содержимое модели в свою модель просмотра, у меня перевернулось животе, но вам просто нужно смириться с тем фактом, что для работы вашего представления потребуется дополнительная часть поведения, которой модель не должна Предоставлю.Независимо от того, насколько это не-DRY, принуждение ваших типов WCF или LINQ to SQL (или любого другого вашего любимого ORM) к реализации INotifyProperyChanged - еще хуже.
Когда я в первый раз копирую и вставляю содержимое модели в свою модель просмотра, у меня перевернулся живот, но вам просто нужно смириться с тем фактом, что для того, чтобы ваше представление работало, ему понадобится этот дополнительный бит поведения, который модель не должна Предоставлю.Независимо от того, насколько это не-DRY, принуждение ваших типов WCF или LINQ to SQL (или любого другого вашего любимого ORM) к реализации INotifyProperyChanged - еще хуже.