Ràng buộc EF4 với Caliburn.Micro: Tôi có nên để Đối tượng của mình là tài sản của ViewModel không?

Question

Với Caliburn.Micro Tôi muốn biết những ưu và khuyết điểm của việc trưng ra một thực thể EF4 như một tài sản của ViewModel (một kỹ thuật được thảo luận hereand here). Điều này cho phép tôi tránh viết getters và setters cho mọi lĩnh vực (xem OneCustomer dưới đây). Hạn chế là tôi cần phải viết tất cả các câu lệnh ràng buộc trong XAML (bên dưới LastName không có trong ViewModel nhưng không yêu cầu ràng buộc XAML). Nếu tôi dính vào kỹ thuật quy định điền vào ViewModel của tôi với các thuộc tính cho mỗi trường (như FirstName bên dưới), cuối cùng tôi sẽ phải viết thêm một tấn mã phụ để NotifyOfProperyChange sẽ được gọi. Ứng dụng sẽ khá lớn. Tôi có nên trưng ra mỗi thực thể như một tài sản của ViewModel không?

Trong ViewModel của tôi:

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

quan điểm của tôi:

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

Cảm ơn trước.

Answer 1

Với Caliburn.Micro Tôi muốn biết những ưu và nhược điểm của việc phơi bày một EF4 Entity như một tài sản của ViewModel (một kỹ thuật thảo luận ở đây và ở đây).

Tôi không chắc chắn về ưu điểm hay khuyết điểm nhưng tôi có thể cho bạn biết cả hai phương pháp đều được sử dụng. Ví dụ lấy một màn hình đăng nhập đơn giản, thông thường tôi đặt UserName một thuộc tính trên ViewModel nhưng trong trường hợp biểu mẫu phức tạp hơn, ViewModel có thể tổng hợp các ViewModels khác (các mô hình hiển thị) để thực hiện điều tương tự. CM không ảnh hưởng đến ưu/khuyết điểm nhiều như câu hỏi của nó về MVVM, những ưu điểm/khuyết điểm là gì. CM sẽ giúp bạn gắn kết với cả hai.

• Nếu bạn có thuộc tính trên ViewModel gọi là CustomerName, chỉ cần đặt tên một TextBox x: name = "CustomerName".
• Nếu bạn có thuộc tính trên ViewModel là phiên bản của một lớp gọi là Khách hàng, hãy đặt tên cho TextBox x: name = "Customer_Name" và một lần nữa, CM sẽ xử lý các ràng buộc.

Vì vậy, từ XAML của bạn ở trên:

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

bạn không cần phải đặt DataContext trên StackPanel.Thay vào đó:

<TextBox x:Name="OneCustomer_LastName"/> 

Một điều có thể liên kết với DataForms và DataGrids dễ dàng hơn là làm theo cách hiển thị cách dữ liệu được hiển thị trên màn hình.

Đây là ý kiến ​​của tôi nhưng cá nhân tôi sẽ không bao giờ liên kết trực tiếp với thực thể EF/Linq. Thay vào đó, tôi sẽ tạo một mô hình hiển thị để đại diện cho thực thể đó và cách tôi muốn nó hiển thị và sử dụng AutoMapper để làm các ánh xạ. Trong nhiều trường hợp, bản đồ của nó là một đối một. Điều này có vẻ như lãng phí thời gian nhưng có ưu điểm đặc biệt với bố cục mô hình dữ liệu phức tạp hơn, mô hình hiển thị cho phép bạn làm phẳng dữ liệu cho mục đích hiển thị và thuộc tính để xác thực mà không gắn chúng vào thực thể mô hình dữ liệu. Để biết thêm về điều đó, hãy xem chương về nó trong ASP.NET MVC in Action cuốn sách.

Answer 2

Vì có những lợi thế khác của việc trưng ra các thực thể (ví dụ, xác thực thông qua các thuộc tính), cá nhân tôi trực tiếp vạch trần chúng.

Nhưng tôi đoán câu trả lời đúng sẽ là "nó phụ thuộc" vì luôn có một số hạn chế (chủ yếu là kiến ​​trúc).

BTW: bạn có thể gọi hộp văn bản "OneCustomer_LastName" và ràng buộc quy ước của C.M sẽ hoạt động.