Wiązanie EF4 z Caliburn.Micro: Czy powinienem wystawić mój podmiot jako właściwość ViewModel?

Question

Z Caliburn.Micro Chciałbym poznać zalety i wady eksponowania jednostki EF4 jako własności ViewModel (technika omawiana pod numerem hereand here). Pozwala mi to uniknąć pisania modułów pobierających i ustawiających dla każdego pola (zobacz OneCustomer poniżej). Wadą jest to, że muszę napisać wszystkie instrukcje wiążące w XAML (poniżej LastName nie jest w ViewModelu, ale wymaga powiązania XAML). Jeśli będę trzymał się przepisanej techniki wypełniania mojego ViewModelu własnymi właściwościami dla każdego pola (jako FirstName poniżej), ostatecznie będę musiał napisać tonę dodatkowego kodu, aby otrzymać wywołanie NotifyOfProperyChange. Aplikacja będzie dość duża. Czy powinienem wystawiać każdy obiekt jako właściwość ViewModel?

In My 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; } } 

moim zdaniem:

<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" /> 

góry dzięki.

Answer 1

Z Caliburn.Micro Chciałbym poznać plusy i minusy poddawanie EF4 podmiotu jako właściwość ViewModel (technika omawianym tutaj i tutaj).

Nie jestem pewien plusy/minusy, ale mogę powiedzieć, że obie metody są używane. Na przykład weź prosty ekran logowania, zazwyczaj umieszczam UserName właściwość na ViewModel, ale w przypadkach, gdy formularz jest bardziej złożony ViewModel może agregować inne ViewModels (modele wyświetlania), aby osiągnąć to samo. CM nie ma wpływu na plusy/minusy, ponieważ jest bardziej kwestią MVVM, jakie są plusy/minusy. CM pomoże ci w związaniu się z oboma.

• Jeśli masz nieruchomość na ViewModel nazywany CustomerName, wystarczy wymienić TextBox x: Name = "CustomerName".
• Jeśli masz właściwość w ViewModel, która jest instancją klasy o nazwie Customer, nazwij TextBox x: name = "Customer_Name" i ponownie, CM zajmie się powiązaniami.

Więc z XAML powyżej:

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

nie trzeba ustawić DataContext na StackPanel.Zamiast:

<TextBox x:Name="OneCustomer_LastName"/> 

Jedną rzeczą, która może sprawić, wiązanie DataForms i datagrids łatwiej jest następująca metoda tworzenia modeli, gdzie wyświetlacz za sposób dane są reprezentowane na ekranie.

To jest moja opinia, ale ja osobiście nigdy nie będę bezpośrednio związany z podmiotem EF/Linq. Zamiast tego utworzę model wyświetlania, który będzie reprezentował tę encję i jak chcę ją wyświetlać i wykorzystywać do jej mapowania. W wielu przypadkach jest to mapowanie jeden na jeden. Może się to wydawać stratą czasu, ale ma ona zalety zwłaszcza w przypadku bardziej złożonych układów modeli danych, modele wyświetlania umożliwiają spłaszczanie danych w celu wyświetlania i przypisywanie właściwości do sprawdzania poprawności bez trzymania ich w jednostce modelu danych. Aby uzyskać więcej informacji na ten temat, przeczytaj rozdział na ten temat w książce ASP.NET MVC in Action.

Answer 2

Ponieważ istnieją inne zalety wystawiania obiektów (na przykład sprawdzanie poprawności za pomocą atrybutów), osobiście wystawiam je bezpośrednio.

Ale myślę, że właściwą odpowiedzią byłoby "to zależy", ponieważ zawsze są też pewne wady (głównie architektoniczne).

BTW: możesz zadzwonić do pola tekstowego "OneCustomer_LastName" oraz do konwencji konwencji C.M.