Lớp dịch vụ có nên trả về các kiểu xem cho một ứng dụng MVC không?

Question

Giả sử bạn có một dự án ASP.NET MVC và đang sử dụng một lớp dịch vụ, chẳng hạn như tiếp xúc này quản lý hướng dẫn trên trang web asp.net: http://www.asp.net/mvc/tutorials/iteration-4-make-the-application-loosely-coupled-cs

Nếu bạn có viewmodels cho quan điểm của bạn, là lớp dịch vụ nơi thích hợp để cung cấp cho mỗi viewmodel? Ví dụ, trong mẫu mã lớp dịch vụ có một phương pháp

public IEnumerable<Contact> ListContacts() 
    { 
     return _repository.ListContacts(); 
    } 

Nếu thay vào đó bạn muốn có một IEnumerable, nó nên đi trong lớp dịch vụ, hoặc là có một nơi khác đó là "đúng" chỗ?

Có lẽ phù hợp hơn, nếu bạn có chế độ xem riêng biệt cho mỗi chế độ xem được liên kết với ContactController, ContactManagerService có phương thức riêng để trả về mỗi chế độ xem không? Nếu lớp dịch vụ không phải là nơi thích hợp, các đối tượng viewmodel sẽ được khởi tạo để sử dụng bởi bộ điều khiển ở đâu?

Answer 1

Nói chung, không.

Xem mô hình nhằm cung cấp thông tin đến và từ lượt xem và phải cụ thể cho ứng dụng, chứ không phải với miền chung. Bộ điều khiển nên phối hợp tương tác với kho, dịch vụ (Tôi đang đưa ra một số giả định về định nghĩa dịch vụ ở đây), vv và xử lý việc xây dựng và xác nhận các mô hình khung nhìn, và cũng chứa logic xác định các khung nhìn để render.

Bằng cách làm rò rỉ mô hình xem thành lớp "dịch vụ", bạn đang làm mờ các lớp và hiện có thể ứng dụng và trình bày cụ thể được trộn lẫn với những gì nên tập trung với trách nhiệm cấp miền.

Answer 2

Tôi cho rằng điều đó phụ thuộc vào những gì bạn xem là "dịch vụ". Tôi chưa bao giờ thực sự thích cụm từ dịch vụ trong ngữ cảnh của một lớp đơn lẻ; nó vô cùng mơ hồ và không cho bạn biết nhiều về mục đích thực sự của lớp.

Nếu "lớp dịch vụ" là một lớp vật lý, chẳng hạn như dịch vụ web, thì tuyệt đối không; các dịch vụ trong ngữ cảnh SOA nên trưng ra các hoạt động miền/doanh nghiệp, không phải dữ liệu và không phải logic trình bày. Nhưng nếu dịch vụ chỉ được sử dụng như một khái niệm trừu tượng cho một mức độ đóng gói cao hơn, tôi không thấy bất kỳ vấn đề nào khi sử dụng nó theo cách bạn mô tả.

Chỉ cần không trộn lẫn các khái niệm. Nếu dịch vụ của bạn thỏa thuận với các mô hình xem thì đó phải là dịch vụ trình bày và được xếp chồng lên trên mô hình thực tế, không bao giờ chạm trực tiếp vào cơ sở dữ liệu hoặc bất kỳ logic nghiệp vụ nào.

Answer 3

Không, tôi không nghĩ vậy. Các dịch vụ chỉ nên quan tâm đến miền có vấn đề, không phải là chế độ xem hiển thị kết quả. Giá trị trả về phải được thể hiện dưới dạng đối tượng miền, chứ không phải dạng xem.

Answer 4

Theo cách tiếp cận truyền thống hoặc lý thuyết khôn ngoan, ViewModel phải là một phần của lớp giao diện người dùng. Ít nhất là cái tên nói như vậy.

Nhưng khi bạn bắt đầu tự thực hiện nó với Khung thực thể, MVC, Kho lưu trữ, v.v, thì bạn sẽ nhận ra điều gì đó khác.

Ai đó phải lập bản đồ Mô hình thực thể/DB với Chế độ xem (DTO được đề cập ở cuối). Điều này có nên được thực hiện trong [A] lớp giao diện người dùng (bởi Bộ điều khiển) hay trong [B] lớp Dịch vụ?

Tôi đi với Tùy chọn B.Tùy chọn A là không không vì thực tế đơn giản là một số mô hình thực thể kết hợp với nhau để tạo thành một ViewModel. Chúng ta không thể truyền dữ liệu không cần thiết cho lớp UI, trong khi trong tùy chọn B, dịch vụ có thể chơi với dữ liệu và chỉ truyền yêu cầu/tối thiểu đến lớp UI sau khi ánh xạ (tới ViewModel).

Một lần nữa, chúng ta hãy đi với tùy chọn A, đặt ViewModel trong lớp giao diện người dùng (và mô hình thực thể trong lớp dịch vụ).

Nếu lớp dịch vụ cần ánh xạ tới ViewModel, thì lớp Dịch vụ cần truy cập ViewModel trong lớp giao diện người dùng. Thư viện/dự án nào? ViewModel phải nằm trong một dự án riêng biệt trong lớp giao diện người dùng và dự án này cần được tham chiếu bởi Lớp dịch vụ. Nếu ViewModel không nằm trong một dự án riêng biệt, thì có tham chiếu vòng tròn, vì vậy không đi. Có vẻ khó xử khi có lớp UI truy cập lớp dịch vụ nhưng chúng tôi vẫn có thể đối phó với nó.

Nhưng điều gì xảy ra nếu có một ứng dụng giao diện người dùng khác sử dụng dịch vụ này? Điều gì sẽ xảy ra nếu có ứng dụng dành cho thiết bị di động? ViewModel có thể khác nhau như thế nào? Dịch vụ có nên truy cập vào cùng một dự án mô hình xem không? Tất cả các dự án giao diện người dùng có truy cập vào cùng một dự án ViewModel hay không?

Sau những cân nhắc này, câu trả lời của tôi là đặt dự án ViewModel trong Lớp dịch vụ. Mỗi lớp giao diện người dùng phải truy cập vào lớp Dịch vụ. Và có thể có rất nhiều ViewModels tương tự mà tất cả chúng có thể sử dụng (do đó ánh xạ trở nên dễ dàng hơn cho lớp dịch vụ). Ánh xạ được thực hiện thông qua LINQ những ngày này, đó là một cộng thêm.

Cuối cùng, có cuộc thảo luận này về DTO. Và cũng về chú thích dữ liệu trong ViewModels. ViewModels với chú thích dữ liệu (Microsoft.Web.Mvc.DataAnnotations.dll) không thể cư trú trong lớp dịch vụ thay vì chúng cư trú trong lớp giao diện người dùng (nhưng ComponentModel.DataAnnotations.dll có thể nằm trong lớp dịch vụ). Vì vậy, DTO thực sự là một ViewModel bởi vì chủ yếu sẽ có một trên một bản đồ giữa hai (nói với AutoMapper). Một lần nữa DTO vẫn có logic cần thiết cho UI (hoặc nhiều ứng dụng) và nằm trong Service Layer. Và lớp UI ViewModel (nếu chúng ta sử dụng Microsoft.Web.Mvc.DataAnnotations.dll) chỉ để sao chép dữ liệu từ DTO, với một số 'hành vi'/thuộc tính được thêm vào nó.

[Bây giờ cuộc thảo luận này là về để có một lượt thú vị hãy đọc tiếp ...: I]

Và đừng nghĩ thuộc tính dữ liệu chú thích là chỉ dành riêng cho giao diện người dùng. Nếu bạn giới hạn xác thực bằng cách sử dụng System.ComponentModel.DataAnnotations.dll thì cùng một viewmodel cũng có thể được sử dụng cho front232 end & xác nhận hợp lệ phụ trợ (do đó loại bỏ UI-residing-viewmodel-copy-of-DTO). Nhiều hơn các thuộc tính cũng có thể được sử dụng trong các mô hình thực thể. Ví dụ: sử dụng .tt, các khung dữ liệu của Entity Framework có thể được tạo tự động với các thuộc tính xác thực để thực hiện một số xác nhận hợp lệ db như độ dài tối đa trước khi gửi đến phần cuối. Một ưu điểm nữa là nếu các thay đổi hợp lệ của backend trong DB thì .tt (đọc db specifics và tạo thuộc tính cho lớp thực thể) sẽ tự động chọn nó. Điều này có thể buộc thử nghiệm đơn vị xác thực UI thất bại, đó là một dấu cộng lớn (vì vậy chúng tôi có thể sửa và thông báo cho tất cả UI/người tiêu dùng thay vì vô tình quên và thất bại). Vâng, cuộc thảo luận đang hướng tới một thiết kế khung tốt. Như bạn có thể thấy, tất cả đều liên quan: xác thực cấp độ khôn ngoan, chiến lược kiểm tra đơn vị, chiến lược bộ nhớ đệm, v.v.

Mặc dù không liên quan trực tiếp đến câu hỏi. 'ViewModel Façade' được đề cập trong này phải xem channel 9 link cũng đáng để khám phá. Nó bắt đầu chính xác ở 11 phút 49 giây trong video. Bởi vì đây sẽ là bước tiếp theo/suy nghĩ khi câu hỏi hiện tại của bạn ở trên được sắp xếp: 'Cách tổ chức chế độ xem?'

Cũng trong ví dụ "_repository.ListContacts()" của bạn đang trả về chế độ xem từ kho lưu trữ. Đây không phải là cách trưởng thành. Các kho lưu trữ nên cung cấp các mô hình thực thể hoặc các mô hình db. Điều này được chuyển đổi thành các mô hình xem và đó là mô hình khung nhìn này được lớp dịch vụ trả về.

Answer 5

Điều này đã đến một chút "nó phụ thuộc" nơi tôi làm việc - chúng tôi thường có một bộ điều khiển tiêu thụ một số dịch vụ - sau đó kết hợp DTO trả về thành 'ViewModel' và sau đó sẽ được truyền cho khách hàng - hoặc thông qua kết quả JSON hoặc bị ràng buộc trong Mẫu dao cạo.

Thing, khoảng 80% thời gian - ánh xạ của DTO tới ViewModel là 1-1. Chúng tôi đang bắt đầu di chuyển về phía 'Khi cần thiết, chỉ cần tiêu thụ trực tiếp DTO, nhưng khi DTO và những gì chúng tôi cần trong ứng dụng/chế độ xem của chúng tôi không khớp - thì chúng tôi tạo ViewModel và thực hiện ánh xạ giữa các đối tượng khi cần'.

Mặc dù tôi vẫn chưa tin rằng đây là giải pháp tốt nhất hoặc đúng - vì nó kết thúc bằng việc thảo luận nóng 'chúng ta chỉ thêm X vào DTO để đáp ứng nhu cầu của chế độ xem?'