Связывание EF4 с Caliburn.Micro: Должен ли я выставить мою сущность как свойство ViewModel? - PullRequest
Новая
       17

Связывание EF4 с Caliburn.Micro: Должен ли я выставить мою сущность как свойство ViewModel?

5 голосов
/ 15 сентября 2011

С Caliburn.Micro Я хотел бы знать плюсы и минусы раскрытия сущности EF4 как свойства ViewModel (методика, обсуждаемая здесь и здесь ).Это позволяет мне избежать записи геттеров и сеттеров для каждого поля (см. OneCustomer ниже).Недостатком является то, что мне нужно написать все операторы привязки в XAML (ниже LastName отсутствует в ViewModel, но требуется привязка XAML).Если я придерживаюсь предписанной методики заполнения моей ViewModel свойствами для каждого поля (как FirstName ниже), мне в конечном итоге придется написать тонну дополнительного кода, просто чтобы вызвать NotifyOfProperyChange.Приложение будет довольно большим. Должен ли я представлять каждую сущность как свойство ViewModel?

В Моей ViewModel: 

private MyEntities _context = new MyEntities();
private BindableCollection<Customer> _custBindableCollection; 
private Customer _oneCustomer;
private string _firstName;

public void Load() 
{
    _custBindableCollection = new BindableCollection<Customer>(_context.Customers.Where(row => row.CustomerType == "FOO"));
    AllCustomers = _custBindableCollection;
    _oneCustomer = _custBindableCollection.FirstOrDefault();
    FirstName = _oneCustomer.FirstName;
    OneCustomer = _oneCustomer;
}

public BindableCollection<Customer> AllCustomers
{ 
get { return _custBindableCollection;}
set {_custBindableCollection = value;
      NotifyOfPropertyChange(() => AllCustomers);}
}

public Customer OneCustomer
{
 get { return _oneCustomer;}
 set { _oneCustomer = value;
        NotifyOfPropertyChange(() => OneCustomer);}
} 

public string FirstName
{
    get { return _firstName; }
    set {
        _firstName = value;
        _oneCustomer.FirstName = value;
        NotifyOfPropertyChange(() => FirstName);
        NotifyOfPropertyChange(() => CanSaveChanges);
    }
}

public void SaveChanges()
{ _context.SaveChanges(); }

public bool CanSaveChanges { get { return IsValid; } }

В Моем представлении:

<StackPanel>
<StackPanel Orientation="Horizontal">
    <Label Content="First Name:" />
    <TextBox x:Name="FirstName" />
</StackPanel>
<StackPanel Orientation="Horizontal" DataContext="{Binding Path=OneCustomer}">
    <Label Content="Last Name:" />
    <TextBox x:Name="LastName" Text="{Binding LastName}" />
</StackPanel>
<Button Content="Load Data" x:Name="Load" />
<Button Content="Save" x:Name="SaveChanges"  />
<DataGrid x:Name="AllCustomers" />

Заранее спасибо.

Ответы [ 2 ]

5 голосов
/ 15 сентября 2011

С Caliburn.Micro Я хотел бы знать плюсы и минусы представления сущности EF4 как свойства ViewModel (методика, обсуждаемая здесь и здесь).

IЯ не уверен в плюсах / минусах, но могу сказать, что используются оба метода.Например, возьмем простой экран входа в систему, обычно я помещаю UserName свойство в ViewModel, но в случаях, когда форма более сложна, ViewModel может объединять другие ViewModels (модели отображения) для достижения той же цели.CM не сильно влияет на плюсы / минусы, так как вопрос в MVVM - каковы плюсы / минусы.CM поможет вам в привязке к обоим.

  • Если у вас есть свойство в ViewModel с именем CustomerName, просто назовите TextBox x: name = "CustomerName".
  • Еслиу вас есть свойство в ViewModel, которое является экземпляром класса с именем Customer, назовите TextBox x: name = "Customer_Name" и снова, CM будет обрабатывать привязки.

Итак, из вашего xaml выше: 

 <TextBox x:Name="LastName" Text="{Binding LastName}" />

вам не нужно устанавливать DataContext на StackPanel.Вместо этого: 

<TextBox x:Name="OneCustomer_LastName"/>

Одна вещь, которая может упростить привязку к DataForms и DataGrids, - это метод, при котором вы создаете модели отображения для способа представления данных на экране.

ЭтоМоё мнение, но я лично никогда не буду связываться напрямую с EF / Linq.Вместо этого я создам модель отображения для представления этой сущности и того, как я хочу, чтобы она отображалась, и использую AutoMapper для сопоставления.Во многих случаях это сопоставление один к одному.Это может показаться пустой тратой времени, но у него есть преимущества, особенно в случае более сложных макетов моделей данных: модели отображения позволяют выравнивать данные для целей отображения и настраивать свойства для проверки, не привязывая их к объекту модели данных.Подробнее об этом читайте в главе ASP.NET MVC в действии книга.

3 голосов
/ 15 сентября 2011

Поскольку существуют другие преимущества предоставления объектов (например, проверка с помощью атрибутов), я лично предоставляю их напрямую.

Но я думаю, что правильным ответом будет "это зависит", поскольку всегда есть и недостатки (в основном архитектурные).

Кстати: вы можете вызвать текстовое поле "OneCustomer_LastName", и соглашение C.M будет работать.

...