Là đơn vị kiểm tra mục tiêu chính của mô hình MVC?

Gần đây trong một cuộc phỏng vấn, một trong những câu hỏi là 'Tại sao chúng ta sử dụng MVC?' Tôi chỉ trả lời rằng nó gần hơn với cách thức, nhiều hệ thống trong thế giới thực! Giải thích về những lợi ích mà nó mang lại khi bảo trì, khả năng mở rộng, v.v. Nhưng họ không bị thuyết phục và cuối cùng nói với tôi rằng MVC được sử dụng chủ yếu vì nó 'cho phép kiểm tra đơn vị dễ dàng'.

Mặc dù tôi biết điểm của họ là một điểm hợp lệ, tôi vẫn nghi ngờ liệu đó có phải là lý do chính bởi vì (i) ngay cả khi tôi quyết định không viết Đơn vị thử nghiệm, MVC là một lựa chọn có thể xảy ra (ii) Nhiều hệ thống GUI có Đơn vị kiểm tra đơn vị không có theo MVC.

Vì vậy, câu hỏi là 'Kiểm tra đơn vị có phải là mục tiêu chính của Mô hình MVC không?'

EDIT: Tôi cho rằng họ có thể đề cập đến sự dễ dàng của Phát triển hướng thử nghiệm / viết N Testit Testcase. Điều này là do chúng tôi có thể ghi lại các mẫu thử nghiệm cho Mô hình (Với điều kiện Chế độ xem phản ánh chính xác các thay đổi trạng thái của Mô hình) - vui lòng sửa lại cho tôi nếu tôi sai.

Mục tiêu chính sẽ là "phân tách các mối quan tâm", vì mô hình, khung nhìn và bộ điều khiển đều có trách nhiệm riêng biệt.

Các tác giả của bài báo Xerox PARC gốc khẳng định rằng:

Mục đích thiết yếu của MVC là thu hẹp khoảng cách giữa mô hình tinh thần của con người và mô hình kỹ thuật số tồn tại trong máy tính.

Nếu thử nghiệm đơn vị là mục tiêu chính, thì người ta có thể dễ dàng xem thử nghiệm đơn vị. Nhìn vào bối cảnh của các dự án / khung thử nghiệm đơn vị sẽ tiết lộ rằng nó hoàn toàn trái ngược với yêu cầu đưa ra. Một người thường sẽ sử dụng các bài kiểm tra tích hợp và chức năng để kiểm tra chế độ xem.

Theo tôi, câu trả lời là một công ty 'không'. Có lẽ đây là lợi ích chính được quan sát thấy trong tổ chức cụ thể này, nhưng tôi sẽ không gọi đó là "mục tiêu chính".

Tôi đoán rằng sẽ không khó để thực hiện MVC theo một cách nào đó, điều đó thật khó khăn để kiểm tra đơn vị (quái - cách tôi làm lần đầu tiên rất khó kiểm tra).

Mặt khác, người ta có thể nói rằng hầu như bất kỳ mô hình nào (ngoại trừ những thứ như Singleton) đều tạo điều kiện cho thử nghiệm đơn vị, vì chúng thường thúc đẩy việc tách rời - nhưng đó có phải là 'mục tiêu chính' của chúng không? Khó khăn.

MVC (giống như hầu hết các mẫu thiết kế đã biết) đã xuất hiện trước khi thử nghiệm đơn vị được biết đến. Cuốn sách GoF đã được xuất bản năm 1994 - và họ chỉ ghi lại các mô hình đã được sử dụng trong nhiều năm (nếu không phải là hàng thập kỷ) trước đó. (Và không có đề cập đến kiểm thử đơn vị trong đó.) Về kiểm thử đơn vị, tôi không thể xác định thời gian chính xác khi nào nó trở thành "công khai" - Cá nhân tôi đã đọc về nó trong các bài viết liên quan đến Lập trình cực đoan và cuốn sách XP đầu tiên ra đời năm 1999

Vì vậy, rõ ràng kiểm thử đơn vị không thể là mục tiêu chính của phát minh / lập tài liệu mẫu - trong khi thật công bằng khi nói rằng các mẫu đó, khi được áp dụng tốt, tạo điều kiện thuận lợi cho kiểm thử đơn vị.

Tôi nghĩ là không, dễ dàng kiểm tra đơn vị là một trong những lợi ích, nhưng nó là một phần của tập hợp các lợi ích khi sử dụng MVC cùng với các lý do bạn liệt kê. Để nói rằng có một lý do chính duy nhất để sử dụng MVC là một sai lầm. Có vẻ như công ty trong câu hỏi chọn MVC để tạo điều kiện cho thử nghiệm đơn vị, do đó họ nghĩ rằng đó là lý do chính. Cá nhân tôi lý do sử dụng MVC là sự đơn giản của nó so với các biểu mẫu web giúp thiết kế và bảo trì dễ dàng hơn, nhưng mỗi cá nhân / công ty sẽ có lý do riêng để sử dụng bất kỳ công nghệ nào.

Trong thế giới ASP.NET MVC, nhiều cải tiến đối với ASP.NET đã được đưa vào chính khung công tác. Mục đích chính của mẫu thiết kế này là tách biệt logic nghiệp vụ khỏi giao diện người dùng để tập trung vào khả năng bảo trì tốt hơn, khả năng kiểm tra được cải thiện và cấu trúc sạch hơn cho ứng dụng.

ASP.NET MVC có một số khả năng nhất định làm cho nó trở thành tùy chọn tốt nhất để chọn nếu bạn cần một hoặc nhiều thứ sau:

• Mức độ kiểm soát cao đối với HTML được tạo : Không giống như Biểu mẫu web, Chế độ xem trong ASP.NET MVC hiển thị HTML chính xác như bạn nói với họ. Gần đây, Web Forms đã được cải thiện trong lĩnh vực này nhưng vẫn không có mức độ kiểm soát mà MVC có.

• Kiểm tra đơn vị dễ dàng hơn : Với ASP.NET MVC, rất dễ thực hiện theo các mẫu kiểm tra như phát triển theo hướng kiểm thử (TDD). Do vòng đời sự kiện phức tạp trong Biểu mẫu web, trên khung công tác dựa trên kiểm soát, TDD dễ dàng hơn rất nhiều với MVC.

• Tách các mối quan tâm : Điều này đề cập đến việc có tất cả các khía cạnh của hệ thống tách biệt rõ ràng với nhau. Do mô hình mà nó thực hiện, một ứng dụng MVC được chia thành các phần rời rạc và lỏng lẻo (mô hình, khung nhìn và bộ điều khiển), giúp dễ dàng bảo trì.

Một số lợi ích khác là:

• Bản thân mẫu MVC giúp quản lý sự phức tạp dễ dàng hơn bằng cách tách biệt rõ ràng chức năng của ứng dụng thành ba phần cốt lõi, mô hình, khung nhìn và bộ điều khiển.

• Các ứng dụng web ASP.NET MVC không sử dụng các biểu mẫu dựa trên trạng thái hoặc máy chủ. Điều này làm cho khung MVC lý tưởng cho các nhà phát triển muốn kiểm soát hoàn toàn hành vi của một ứng dụng. Trạng thái xem có thể trở nên rất lớn, đó là một vấn đề đối với các thiết bị như điện thoại thông minh chạy trên mạng chậm (truyền tất cả thông tin có thể rất chậm). Trong trang Web Forms, bạn chỉ có thể có một trang trên mỗi trang. Đây là một hạn chế khá lớn. Trong MVC, không có giới hạn nào như vậy, đó là, bạn có thể có bao nhiêu yếu tố tùy thích.

• ASP.NET MVC cung cấp hỗ trợ tốt hơn cho phát triển dựa trên thử nghiệm (TDD).

• ASP.NET MVC hoạt động tốt cho các ứng dụng web được hỗ trợ bởi các nhóm lớn các nhà phát triển và cho các nhà thiết kế web, những người cần mức độ kiểm soát cao đối với HTML. Xử lý yêu cầu ASP.NET MVC