2016-03-04 2 views
0

==> а) объекты UI Model: то есть класс, который у меня есть свойства изменить уведомление (INotifyPropertyChanged), SelectedItemXXX переплетены в некоторых ComboBox SelectedItemКак отличить UI связывание объектов модели и объекты Модель которые передаются среднего уровня

==> b) Объекты модели: Просто простой objecti.e POCO (обычный объект CLR)

Вопрос 1) В общем, чем лучше иметь такие модели. Я имею в виду, что нам нужно просто поддерживать только модель (a)?

Вопрос 2) Если мы поддерживаем две модели. У вас лучший способ иметь. Можем ли мы иметь некоторую ассоциацию или какой-либо метод для создания объекта модели (b).

Вопрос 3) Что общего в названии соглашения, если у нас есть две модели. Я назвал это как PersonUI, Лицо, я имею в виду, лучший способ для именования?

Thankyou

ответ

2

Ответ на вопрос 1: Нет. Вам часто требуются простые объекты модели для выполнения бизнес-логики реального мира (так называемой логики домена) вне сферы ваших моделей пользовательского интерфейса. Следуя Single Responsibility Principal, вы не должны свертывать объекты модели пользовательского интерфейса с объектами бизнес-модели.

Ответ на вопрос 2: Да - Очень часто использующаяся модель MVVM:

  • M - представляет собой модель (бизнес или логики домена слой)
  • V - представляет собой вид (в WPF и Silverlight это XAML и код позади)
  • VM представляет ViewModel (или в ваших словах объекты UI Model)

М.В. VM рекомендуется передовая практика как для WPF, так и для SilverLight. Он отделяет пользовательский интерфейс от модели и позволяет упростить тестирование и повторное использование.

Ответ на вопрос 3: Общее соглашение об именах для объектов модели UI (a) заключается в использовании XXXXViewModel. Например, если у вас есть контроль над WPF с именем Giraffe.xaml и соответствующий код позади файла Giraffe.xaml.cs, то название вашей модели файл представления будет GiraffeViewModel.cs и класс будет выглядеть примерно так:

public class GiraffeViewModel : INotifyPropertyChanged {..

Держите имена модельных объектов к логике, которая содержится внутри. Например: GiraffeVision.cs

+0

В этом случае проблема с соглашением об именах. Позволяет нам иметь вид регистрации сотрудника и соответствующий вид Model i.e EmployeeRegisterViewModel. Теперь EmployeeRegisterView нуждается в каком-то объекте, который должен быть ограничен конкретным элементом управления пользовательским интерфейсом, позволяет говорить EmployeePersonal информацию, где нужно поймать SelectedItem. если я назову этот объект как EmployeePersonalInfoViewModel, тогда он будет длинным списком ViewModels, который смущает, когда мы хотим найти MainViewModel (EmployeeRegisterViewModel) для работы с проблемой получения данных. Например, для GetData не работает. – iCode

+0

В этом случае ваши объекты EmployeePersonalInformation будут объектом ObservableCollection в EmployeeRegisterViewModel. ObservableCollections - это списки объекта Model, используемые в сетках или шаблонах, поэтому вы можете отображать многие из них в своем представлении. См. Http: //wpfgrid.blogspot.de/2014/02/simple-observablecollection-wpf-mvvm.html - обратите внимание на класс модели Trades на полпути. Эта модель домена помещается в ObservableCollection для динамического отображения в TradesView. – Taterhead

+0

В действительности, это не объект коллекции. Я просто дал образец сценария. Нам нужно поддерживать объекты привязки, которые не являются элементами коллекции. Они похожи друг на друга. Но мне нужно получить информацию из интерфейса пользовательского интерфейса. Этот элемент управления пользовательского интерфейса должен быть привязан к некоторому объекту (т.е. INotifiable, SelectedXXX ..). Фактически это ViewModel. Но теперь, если я назову его как XXX_ViewModel ... его путают много ... для поиска файлов .., чтобы найти MainViewModel (где фактическая логика идет для вызова среднего уровня и других материалов comamnds). – iCode