Trong MVC3, tôi có phải có các mô hình "chỉnh sửa" riêng biệt so với các mô hình "hiển thị" không?

Question

Với MVC3, tôi có nên thiết kế các kiểu xem của mình sao cho có mô hình được gắn với khung nhìn (DisplayModel) và một mô hình được đăng lại bộ điều khiển (EditModel) không?

Để làm rõ, tôi không hỏi về các mô hình dữ liệu so với các mô hình xem - Tôi biết sẽ không tốt nếu ràng buộc các khung nhìn/bộ điều khiển của tôi với các mô hình dữ liệu/tên miền.

Tôi cũng không hỏi về việc chia sẻ một mô hình trên hai chế độ xem riêng biệt, một chế độ xem được sử dụng để hiển thị dữ liệu và chế độ xem khác được sử dụng để chỉnh sửa dữ liệu.

Thay vào đó, tôi hỏi về một chế độ xem được sử dụng để chỉnh sửa dữ liệu và mô hình được ràng buộc với chế độ xem so với mô hình bị ràng buộc với hành động của bộ điều khiển.

Nói cách khác, nếu điều này là quan điểm của tôi:

@model MyApp.Models.CustomerModel 

nên điều khiển nhìn hành động của tôi như:

public ActionResult Index(CustomerModel model) 

Hoặc:

public ActionResult Index(CustomerEditModel model) 

Tại một thời điểm, chúng tôi đã làm việc sau (riêng biệt). Nhưng gần đây, chúng tôi đã bắt đầu làm việc trước đây (được chia sẻ).

Lý do cho sự thay đổi này là vì:

1. Với MVC3 xác nhận không phô trương, nếu tôi đang sử dụng DataAnnotations trên mô hình của tôi để xác nhận, điều này là cần thiết trong cả hai mô hình nếu chúng được tách ra (trên màn hình mô hình để ánh xạ xác thực phía máy khách và trên mô hình chỉnh sửa để xác thực phía máy chủ).

2. Khi ứng dụng của chúng tôi trưởng thành, chúng tôi nhận thấy rằng các mô hình hiển thị và chỉnh sửa của chúng tôi giống hệt nhau 95%, ngoại trừ các danh sách chọn trong các kiểu xem của chúng tôi. Bây giờ, chúng tôi đã chuyển các mục này sang một số shared class và chuyển các thông số này qua qua chế độ xem ngay bây giờ.

Nhưng tôi đã nhìn thấy một số cuộc thảo luận khác trỏ đến có mô hình chung cho xem/điều khiển là một ý tưởng tồi, và rằng it violates tách mối quan tâm.

Ai đó có thể giúp tôi hiểu sự cân bằng cho hai cách tiếp cận này không?

Answer 1

Tôi đã nhìn thấy các đối số hoàn toàn tốt và chống lại, nó chỉ phụ thuộc vào những gì làm việc tốt nhất cho ứng dụng của bạn. Không có một kích thước phù hợp với tất cả các phương pháp có thể được áp dụng!

Nếu bạn chưa đọc nó Jimmy Bogard đã viết một bài rất hay về cách đội của anh ấy làm MVC here, bao gồm chủ đề này.

Answer 2

Nếu các thuộc tính giống nhau đối với các kiểu xem hiển thị và chỉnh sửa, tôi không thấy lý do nào để có các lớp riêng biệt.

Answer 3

Tôi nghĩ bạn sẽ thấy rằng nó bị trúng hoặc bỏ lỡ bất kể bạn đi theo cách nào nhưng nếu bạn có thể đảm bảo đường đi dễ bảo trì nhất thì bạn nên làm điều đó. Theo kinh nghiệm của tôi, có một mô hình duy nhất dễ dàng hơn nhiều để duy trì, rõ ràng, nhưng có vẻ như luôn có một số quyết định kinh doanh được đưa ra buộc tôi phải phân chia các mô hình. Nếu bạn đang ở trong đó 95% sau đó tôi nghĩ rằng bạn đang ở trong hình dạng thực sự tốt.Ứng dụng của bạn, từ quan điểm bảo trì liên quan đến các mô hình của bạn, sẽ dễ bảo trì. Khi một thay đổi xuất hiện, bạn có một nơi để thực hiện thay đổi đó, phần lớn. Vấn đề tôi dường như luôn gặp phải là việc thay đổi quy mô kinh doanh trên nhiều mô hình. Sao chép/dán các vấn đề, hoặc chỉ đơn giản là quên đi một số tài sản ở đâu đó, luôn luôn có vẻ làm tổn thương tôi vì vấn đề đa mô hình.

Answer 4

chúng tôi nhận thấy rằng các mô hình hiển thị và chỉnh sửa của chúng tôi giống hệt nhau 95%, với ngoại lệ của các danh sách chọn trong các kiểu xem của chúng tôi. Bây giờ chúng tôi đã di chuyển các mục này sang một lớp học được chia sẻ và sẽ chuyển các thông tin này qua qua chế độ xem ngay bây giờ.

Chúng 95% giống hệt nhau về dữ liệu và hoạt động hay chỉ trong dữ liệu? Hãy nhớ rằng các lớp đóng gói dữ liệu và hành vi.

Nếu chúng tương tự 95% thuộc tính nhưng có các hoạt động hoàn toàn khác nhau, bạn có thể hưởng lợi từ việc chia chúng thành hai lớp. Hoặc bạn có thể không :)

Khi người khác chỉ ra không có câu trả lời một kích thước phù hợp và trong trường hợp của bạn có vẻ như một lớp là OK ... nhưng nếu bạn bắt đầu nhận thấy rằng hành vi trên mỗi chúng không liên quan đến nhau, đừng ngại suy nghĩ lại cách tiếp cận của bạn.

Answer 5

Không có mô hình xem một cho cả hai hướng. Trộn nó lên không chỉ khó theo, mà người ta có thể dễ dàng tiêm các giá trị không hợp lệ vào trang mà sau đó tự động bị ràng buộc. Tôi có thể ghi đè lên customerid của bạn (hoặc tạo ra một) ví dụ.

Thừa kế từ mô hình chế độ xem cơ sở nếu bạn phải hoặc không dựa vào chú thích dữ liệu và sử dụng api thông thạo trên mô hình của bạn.

Một liên kết tuyệt vời (phần không liên quan nhưng bản đồ tự động là tốt đẹp)

chỉnh sửa (xin lỗi người khác trước đó được đăng dưới đây tôi chỉ nhận ra) http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/

Cũng ASP.net MVC - One ViewModel per View or per Action?

Bạn (IMHO) nên nói chung ràng buộc với phương pháp cụ thể VieWModel của bạn chứ không phải là một mô hình xem chia sẻ. Bạn có thể bị bắt trong một cái bẫy của tài sản bị mất tích, vv nhưng nó cũng có thể làm việc tốt cho bạn.

Sử dụng trình ánh xạ tự động để di chuyển giữa cả hai. Jimmy cũng có một thuộc tính AutoMap tốt đẹp khi trở về View. Quay lại theo cách khác, tôi sẽ không sử dụng CustomerModel nói chung vì có thể có các trường bắt buộc trong đó không phải là từ lời nói của tôi, tạo ra khung nhìn. Ví dụ: id khách hàng có thể là trường bắt buộc và cho hành động "tạo", nó sẽ không có mặt. Nhưng - nếu bạn thấy trong hầu hết các trường hợp của bạn điều này để thực sự làm việc cho bạn, sau đó không có lý do gì cả để không sử dụng nó.

Answer 6

Tôi đồng ý với rich.okelly's answer rằng không có cách tiếp cận phù hợp.

Tuy nhiên, có một vài lo ngại mà tôi có khi sử dụng một mô hình.

Sẽ rất dễ sử dụng một mô hình mà không có các thuộc tính không cần thiết khi chế độ xem cần hiển thị danh sách các đối tượng có thể chọn. Mô hình sẽ cần phải có danh sách các đối tượng cũng như một thuộc tính để chấp nhận giá trị POST mà người dùng chọn. Những thuộc tính không cần thiết này thêm một lượng nhỏ mã lộn xộn và trên không. (Một cách xung quanh việc này là để mô hình chỉ chứa ID được chọn và có người trợ giúp HTML để tạo danh sách.)

Một mối quan ngại khác liên quan đến bảo mật hơn. Một tình huống phổ biến là hiển thị thông tin trong một biểu mẫu nên được coi là chỉ đọc. Trong trường hợp của một ViewModel và một EditModel, EditModel sẽ chỉ chứa các thuộc tính được dự kiến ​​sẽ được POST, trong khi ViewModel sẽ chứa tất cả các thuộc tính. Ví dụ, nếu một biểu mẫu hiển thị tiền lương của người dùng, người dùng sẽ có thể POST một 'tiền lương' và có nó ràng buộc với tài sản lương của ViewModel tự động bởi MVC. Tại thời điểm này, something phải được thực hiện để đảm bảo nó không kết thúc trong cơ sở dữ liệu. Nó có thể là if/else logic, một thuộc tính Bind, Automapper logic hay cái gì khác, nhưng vấn đề là nó là một bước có thể bị bỏ qua. Khi xem xét tuổi thọ của một ứng dụng, tôi thích nhân chứng của EditModel theo thời gian.

Những mối quan tâm này không có nghĩa là hai mô hình là tốt và một mô hình là xấu, nhưng chúng nên được xem xét khi chọn thiết kế.