ASP.NET MVC - M, V và C của MVC có nên nhận thức rõ ràng về các thực thể miền không?


8

Vì câu hỏi này có vẻ khá chủ quan, tôi sẽ đăng nó ở đây.

Hãy nói rằng bạn đang viết phiên bản của riêng bạn Stackoverflow sử dụng ASP.NET MVC, vì vậy có những lớp học như Question, Answer, User, vv Kể từ khi bạn lười biếng, bạn quyết định sử dụng khuôn khổ thực thể. Vì vậy, tất cả các lớp được đề cập ở trên có thuộc tính điều hướng: Questionbiết Answers của nó , Answerbiết Userai đã đăng nó, v.v.

Bạn đã đọc rất nhiều sách của Martin Fowler, vì vậy chắc chắn bạn sẽ có một lớp dịch vụ để thực hiện tất cả logic kinh doanh ở đó. Bạn sẽ chỉ sử dụng ASP.NET MVC cho giao diện người dùng và chức năng liên quan đến logic ứng dụng.

Có 2 câu hỏi:

  1. Bạn sẽ trực tiếp tiếp xúc với đối tượng Question, Answervà những người khác đến điều khiển?
  2. Bạn sẽ làm tương tự cho quan điểm?

Về cơ bản, tôi sẽ không cung cấp API REST cho ứng dụng của mình, tôi cũng không quá bảo thủ khi chỉ có bất kỳ nỗi sợ hãi nào như "này, MY VIEW nhận thức được điều đó Questionlà gì , tôi không biết nó có tệ hay không, Tôi chỉ không thích nó! ".

Tôi đặc biệt tò mò về trường hợp khi Questionlớp có một lĩnh vực như TimePostedvà bạn ràng buộc của bạn PostNewQuestionnhằm lớp đó. Tôi biết rằng trong trường hợp tôi không ràng buộc trường đó với bất kỳ điều khiển nào trên trang, nó sẽ không được đăng, vì vậy tôi sẽ đặt trường đó thành nullkhi tôi có đối tượng ở phía trình điều khiển của mình. Nó được coi là tốt hay là ý tưởng tồi? 2 cách tiếp cận ngược lại tôi nghĩ là "sử dụng DTOs / ViewModels ở mọi nơi" và "wtf, ít lớp hơn luôn tốt hơn!"

Bạn nghĩ gì là một cách tiếp cận đúng ? (Tôi biết không có câu trả lời trực tiếp, vì vậy, câu hỏi thực tế là "người ta nên cân nhắc điều gì để quyết định xem có sử dụng DTOs / ViewModels / Bất cứ điều gì khác tốt cho kiến ​​trúc ứng dụng của nó không?")

Ngoài ra, xin lưu ý rằng chúng tôi đang xem xét một bản sao rất đơn giản của Stackoverflow, vì vậy:

  1. Đây là một dự án chỉ dành cho web (chúng tôi sẽ không tiết lộ API REST hoặc bất cứ điều gì khác)
  2. Có người dùng, câu hỏi, câu trả lời, thẻ và chức năng tìm kiếm (không có logic kinh doanh nổi bật)
  3. Có khoảng 100 người dùng hoạt động mỗi ngày (không yêu cầu hiệu suất đặc biệt)
  4. Mã phải dễ đọc và không có bất ngờ hoặc địa điểm nào được quan tâm đặc biệt trong trường hợp thành viên mới gia nhập nhóm nhà phát triển.

Bạn cũng có thể bày tỏ suy nghĩ của mình trong trường hợp bất kỳ 3 điểm đầu tiên nào bị thay đổi - "khách hàng hiện muốn dịch vụ của chúng tôi cho phép 10000 người dùng đồng thời" hoặc "chúng tôi hiện chỉ cần cho phép mỗi người dùng đăng một lần trong 15 phút", v.v.

Cảm ơn!

Câu trả lời:


3

Tôi đã không làm việc nhiều với MVC, tuy nhiên tôi đã làm việc rất nhiều với MVVM và đây là cách tôi thực hiện:

Question, AnswerUserlà tất cả các đối tượng dữ liệu. Họ có thể biết về nhau, nhưng họ không nên biết bất cứ điều gì bên ngoài lớp đối tượng dữ liệu, chẳng hạn như Chế độ xem, Bộ điều khiển, ViewModels, v.v.

Trong một thế giới lý tưởng, Chế độ xem của bạn chỉ tham chiếu các Mô hình. Họ có thể biết về Bộ điều khiển, nhưng họ không cần phải tham khảo trực tiếp. ViewModel chỉ biết các Model khác. Bộ điều khiển biết về Mô hình và ViewModels. Nó hoàn toàn không quan tâm đến Chế độ xem, mặc dù nó cung cấp Chế độ xem với Chế độ xem hoặc Mô hình.

Vì vậy, các đối tượng của bạn cuối cùng trông như thế này:

  • M odels có hai loại: Model và ViewModels.

    • Các mô hình là các đối tượng dữ liệu đơn giản tồn tại đơn giản để chứa dữ liệu và nói chung là sự phản ánh dữ liệu cơ sở dữ liệu. Họ không truy cập cơ sở dữ liệu hoặc chứa bất kỳ loại logic kinh doanh nào không liên quan đến họ.
    • ViewModels là các đối tượng dữ liệu chứa dữ liệu mà View cần, không nhất thiết là những gì cơ sở dữ liệu cần. Chúng có thể chứa Mô hình, mặc dù Mô hình không nên chứa ViewModels.
  • C ontrollers chứa logic kinh doanh của bạn. Chúng kiểm soát các cuộc gọi truy cập dữ liệu, tạo Mô hình / ViewModels để chuyển đến Chế độ xem, logic nghiệp vụ nâng cao như quyền, v.v. Về cơ bản, chúng điều khiển toàn bộ lớp mã.

  • V iews chỉ được sử dụng để cung cấp cho người dùng giao diện thân thiện với người dùng. Họ chấp nhận ViewModel hoặc Model và hiển thị nó theo cách nào đó trông đẹp mắt cho người dùng.


MVVM không thực sự có ý nghĩa trong một dự án web ...
yannis

1
@YannisRizos Đây không phải là MVVM, đó là MVC. MVC cũng có ViewModels, nhưng chúng là một phần của lớp Model. Về cơ bản, chúng là các mô hình cho các khung nhìn, không phải lớp riêng chứa logic nghiệp vụ (đó là những gì chúng có trong MVVM). Tôi thực sự không khuyên bạn nên sử dụng MVVM trừ khi bạn làm việc với WPF / Silverlight.
Rachel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.