Có phải MVC chống OOP không?

Ý tưởng chính đằng sau OOP là thống nhất dữ liệu và hành vi trong một thực thể duy nhất - đối tượng. Trong lập trình thủ tục có dữ liệu và các thuật toán riêng biệt sửa đổi dữ liệu.

Trong mẫu Model-View-Controller, dữ liệu và logic / thuật toán được đặt trong các thực thể riêng biệt, mô hình và bộ điều khiển tương ứng. Trong cách tiếp cận OOP tương đương, không nên đặt mô hình và bộ điều khiển trong cùng một thực thể logic?

MVC là một bài tập trong Tách biệt các mối quan tâm , một kiến ​​trúc UI. Đó là một cách để củng cố sự phức tạp có thể xảy ra trong giao diện người dùng do bản trình bày không được tách rời khỏi nội dung .

Về lý thuyết, tất cả các đối tượng có thể có hành vi hoạt động trên dữ liệu mà chúng chứa và dữ liệu và hành vi đó vẫn được gói gọn . Trong thực tế, một đối tượng OOP nhất định có thể có hoặc không có logic tương ứng với dữ liệu của nó hoặc có thể không có bất kỳ logic nào ( ví dụ: Đối tượng truyền dữ liệu ).

Trong MVC, logic nghiệp vụ đi theo mô hình chứ không phải bộ điều khiển. Bộ điều khiển thực sự chỉ là một phần giữa để kết hợp Chế độ xem và Mô hình. Vì vậy, trong mô hình, bạn có thể có dữ liệu và hành vi ở cùng một nơi.

Nhưng ngay cả sự sắp xếp đó cũng không đảm bảo hợp nhất dữ liệu / hành vi. Các đối tượng chỉ chứa dữ liệu có thể được vận hành bởi các lớp khác chỉ chứa logic và đây là cách sử dụng OOP hoàn toàn chấp nhận được.

Tôi sẽ cho bạn một ví dụ cụ thể. Đây là một chút giả định, nhưng giả sử bạn có một Currencyđối tượng và đối tượng đó có khả năng tự đại diện bằng bất kỳ loại tiền tệ có sẵn nào, được chốt bằng đồng đô la. Vì vậy, bạn sẽ có các phương pháp như:

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... Và hành vi đó sẽ được gói gọn với đối tượng Tiền tệ.

Nhưng nếu tôi muốn chuyển tiền từ tài khoản này sang tài khoản khác hoặc gửi một số loại tiền thì sao? Hành vi đó cũng sẽ được gói gọn trong đối tượng Tiền tệ? Không, nó sẽ không. Tiền trong ví của bạn không thể tự chuyển ra khỏi ví vào tài khoản ngân hàng của bạn; bạn cần một hoặc nhiều đại lý (giao dịch viên hoặc ATM) để hỗ trợ nhận số tiền đó vào tài khoản của bạn.

Vì vậy, hành vi đó sẽ được gói gọn trong một Tellerđối tượng và nó sẽ chấp nhận Currencyvà Accountcác đối tượng là đầu vào, nhưng nó sẽ không chứa bất kỳ dữ liệu nào, ngoại trừ một chút trạng thái cục bộ (hoặc có thể là một Transactionđối tượng) để giúp xử lý các đối tượng đầu vào.

MVC làm việc tại một nhiều mức trừu tượng cao hơn so với đối tượng duy nhất, và trong thực tế mỗi ba (model, view, controller) thường sẽ bao gồm nhiều đối tượng mà mỗi người đều có cả dữ liệu và hành vi.

Các đối tượng đóng gói dữ liệu và hành vi là một khối xây dựng cơ bản tốt cho các chương trình nói chung không có nghĩa đó là mô hình tốt nhất ở mọi cấp độ trừu tượng và cho tất cả các mục đích.

OOP không hạn chế sự tương tác giữa các đối tượng mà mỗi đối tượng có dữ liệu riêng và hành vi của riêng họ.

Hãy nghĩ về một con kiến ​​và một loài kiến ​​tương tự: hành vi của một con kiến ​​(chạy suốt ngày, mang thức ăn) khác với hành vi của thuộc địa tổng thể (tìm nơi mong muốn nhất, tạo ra nhiều con kiến ​​hơn). Mẫu MVC mô tả cấu trúc xã hội mong muốn của một đàn kiến, trong khi OOP hướng dẫn thiết kế từng con kiến.

OOP cũng là về Tách các mối quan tâm , nghĩa là phân tách các vai trò / khả năng đáp ứng khác nhau trong các đối tượng khác nhau.

MVC tách thành các thành phần sau:

• Mô hình: dữ liệu và logic kinh doanh của nó
• Xem: đại diện của dữ liệu
• Điều khiển: phối hợp giữa mô hình và khung nhìn.

Vì vậy, các khả năng đáp ứng này rõ ràng khác biệt và thực sự nên được tách thành nhiều thực thể.

Trong mẫu Model-View-Controller, dữ liệu và logic / thuật toán được đặt trong các thực thể riêng biệt, mô hình và bộ điều khiển tương ứng.

Mô hình và bộ điều khiển là hai vai trò riêng biệt. Một mô hình có cả trạng thái và logic, và bộ điều khiển có cả trạng thái và logic. Thực tế là chúng giao tiếp không phá vỡ sự đóng gói của một trong hai - bộ điều khiển không biết hoặc quan tâm đến cách mô hình lưu trữ dữ liệu của nó hoặc những gì nó làm với dữ liệu khi bộ điều khiển lấy hoặc cập nhật một phần của nó. Mô hình không biết hoặc quan tâm bộ điều khiển làm gì với dữ liệu mà mô hình cung cấp.

Hãy nghĩ về nó theo cách này: nếu các đối tượng không thể truyền dữ liệu qua lại mà không phá vỡ đóng gói, bạn thực sự chỉ có thể có một đối tượng!

Trong cách tiếp cận OOP tương đương, không nên đặt mô hình và bộ điều khiển trong cùng một thực thể logic?

MVC là một cách tiếp cận OOP - cụ thể, đó là một công thức để quyết định cách sử dụng các đối tượng để tổ chức một chương trình hiệu quả. Và không , mô hình và bộ điều khiển không nên là cùng một thực thể. Một bộ điều khiển cho phép tách giữa mô hình và khung nhìn. Giữ mô hình và chế độ xem độc lập với nhau làm cho cả hai dễ kiểm tra hơn và có thể tái sử dụng nhiều hơn.

MVC là một mô hình mô tả một cách hợp lý cho các đối tượng tương tác; bản thân nó không phải là một siêu lớp. Ở đó, OO là về việc mô tả các hành vi và dữ liệu của các thực thể và cách các thực thể nói tương tác với nhau. Nó không phải là về việc hợp nhất toàn bộ hệ thống thành một đối tượng lớn.

Bộ điều khiển không đại diện cho hành vi của một mô hình. Bộ điều khiển hoàn toàn đại diện cho hành vi của toàn bộ ứng dụng _ những gì người dùng có thể làm và những gì người dùng có thể thấy.

Thật sai lầm khi xem bộ điều khiển và mô hình là một. Chúng có các mục đích khác nhau, ngữ nghĩa khác nhau và do đó không nên thống nhất trong một đối tượng.

Lớp mô hình không chỉ đơn thuần là dữ liệu nhiều hơn lớp điều khiển chỉ là logic.

Lớp điều khiển sẽ có một bộ sưu tập đầy đủ các đối tượng cho mục đích của nó. Sẽ có các đối tượng để nhận đầu vào từ khung nhìn và từ việc chuyển đổi đầu vào đó thành một dạng mà mô hình có thể xử lý. Khung công tác Java Struts có một ví dụ hay về điều này trong mô hình Hành động / Biểu mẫu. Biểu mẫu được điền với đầu vào từ người dùng và sau đó được chuyển đến Hành động. Hành động lấy dữ liệu đó và sử dụng nó để thao tác mô hình.

Theo cùng một cách, lớp Model không bao gồm toàn bộ dữ liệu. Lấy một đối tượng Người dùng, ví dụ - bạn có thể cần mã lấy người dùng từ cơ sở dữ liệu hoặc mã để liên kết Người dùng với Đơn hàng hoặc để xác thực rằng địa chỉ của Người dùng nằm trong khu vực dịch vụ của công ty bạn ... bạn có được hình ảnh. Đây không phải là logic điều khiển. Đó là logic kinh doanh và nó đã khiến nhiều người chia lớp Mô hình của họ thành nhiều lớp như lớp Dịch vụ hoặc Trình quản lý cho logic nghiệp vụ, lớp DAO (Đối tượng truy cập cơ sở dữ liệu) để truy cập cơ sở dữ liệu và các lớp khác.

MVC không phải là một phương thức để tổ chức các hoạt động Mô hình riêng lẻ. Nó hoạt động ở mức cao hơn thế - đó là một phương pháp để tổ chức cách truy cập ứng dụng. Chế độ xem là để trình bày dữ liệu và hành động của con người để thao túng nó, Bộ điều khiển dành cho dịch giữa các hành động của người dùng và các chế độ xem khác nhau và Mô hình là nơi chứa dữ liệu kinh doanh và lý do kinh doanh để nó tồn tại.

Quan điểm của OOP là nhóm các dữ liệu và chức năng thuộc về nhau . Một tính toán dựa trên một số phần dữ liệu không phải lúc nào cũng thuộc về dữ liệu đó.

Trong MVC, chức năng hiển thị một phần dữ liệu (khung nhìn) được tách biệt với dữ liệu (mô hình). Tại sao vậy? Nó đặc biệt để logic hiển thị có thể được thay đổi mà không phải thay đổi dữ liệu cơ bản. Nó giúp bạn dễ dàng thay đổi chế độ xem bất cứ khi nào bạn cần thực hiện một bản trình bày khác nhau của cùng một dữ liệu: hoặc khi các đặc điểm của phần cứng hiển thị thay đổi: hoặc khi bạn chuyển từ Windows sang Linux; hoặc khi bạn muốn hai người có hai cách nhìn khác nhau về cùng một dữ liệu.

MVC không mâu thuẫn với OOP - nó thực sự bắt nguồn từ một ứng dụng chính xác của Nguyên tắc hướng đối tượng.

Tôi tin rằng bạn đang nhầm lẫn dữ liệu liên tục liên kết với một đối tượng mô hình với dữ liệu ứng dụng từ cơ sở dữ liệu mà mô hình tương tác với. Một mô hình chứa logic kinh doanh và các quy tắc để làm việc với cơ sở dữ liệu và thực hiện các giao dịch. Nó có thể đặt và kiểm tra các cờ trạng thái nội bộ như ngày hôm nay có bán hay không, liệu người dùng có đủ điều kiện nhận trạng thái VIP và sau đó phân nhánh logic phù hợp khi đến lúc truy cập, đặt hoặc thao tác dữ liệu hoặc tiến hành mua hàng. Đó là những lá cờ mà chúng ta đang nói đến khi chúng ta thảo luận về các đối tượng về mặt đóng gói của một tập hợp các phương thức và các giá trị hoặc dữ liệu liên tục.

Giống như đối tượng mô hình duy trì dữ liệu để thiết lập quy tắc kinh doanh nào đang diễn ra, IMO, bộ điều khiển nên giữ dữ liệu trạng thái ứng dụng chung hơn phù hợp với cách ứng dụng nên hoạt động, như người dùng đã đăng nhập hay họ có tín dụng hợp lệ dữ liệu thẻ tại chỗ. Các phương thức mô hình sẽ xác định trạng thái của những điều này ngay từ đầu nhưng điều hợp lý là bộ điều khiển sẽ duy trì các cờ phù hợp với luồng ứng dụng chung nếu chúng không áp dụng cho cách thức hoạt động của doanh nghiệp hoặc giao dịch dữ liệu. Khi bạn đã xác định rằng họ chưa đăng nhập, thậm chí đừng làm phiền mô hình với kiểm tra trạng thái người dùng cho đến khi rõ ràng một nỗ lực đăng nhập khác đang được thực hiện.

Tương tự như vậy với một đối tượng xem phù hợp so với các mẫu HTML điển hình hơn mà bạn thấy trong hầu hết các khung web phía máy chủ. Khi tùy chọn màu của người dùng được tải lên, nó sẽ là chế độ xem giữ dữ liệu đó và thực thi trên đó. Tải, xác thực và thay đổi cài đặt là tất cả các sự cố mô hình nhưng chúng chỉ nên là sự cố mô hình một lần cho đến khi thay đổi xảy ra.

IMO, không có gì nói các bộ điều khiển không thể là các đối tượng tổng hợp với các khung nhìn và các mô hình như các đối tượng tổng hợp bên trong. Điều này thực sự có ý nghĩa nếu bạn áp dụng MVC ở quy mô nhỏ hơn như nhà máy widget UI vì bộ điều khiển là nơi lý tưởng để hiển thị giao diện cho các đối tượng ứng dụng cấp cao hơn trong khi chôn vùi dữ liệu và chi tiết logic về cách tương tác của View và Model. Nó không thực sự có ý nghĩa đối với các đối tượng ứng dụng đơn nhân trong đó bộ điều khiển thực sự là đối tượng cấp cao nhất.

Như tôi hiểu nó; Đối số là kiến ​​trúc dựa trên thành phần so với OOP. Và không tham gia vào cuộc chiến tôn giáo, tôi nghĩ rằng cả hai đều mô tả cùng một điều; chỉ nhìn nó từ các góc độ khác nhau.

Ví dụ, toàn bộ quan điểm của OOP / OOD là làm cho mã của bạn trở nên mô đun hơn và có thể sử dụng lại. Đúng?

Đó chính xác là mục tiêu của kiến ​​trúc dựa trên thành phần. Vì vậy, họ giống nhau hơn bất cứ điều gì khác.

Tôi nghĩ rằng MVC chỉ là sự phát triển tự nhiên của OOP và tôi dám nói điều đó; một cách tốt hơn để tổ chức các đối tượng của bạn, tách các mối quan tâm và tái sử dụng mã.

Tôi đến trễ bữa tiệc này và xem xét tất cả các câu trả lời trước tôi, tôi thừa nhận tôi không có nhiều điều mới mẻ để cung cấp. Nhưng đối với tôi, câu hỏi không phải là về bản thân mẫu mà là về cách thực hiện. MVC trong và bản thân nó không cho vay bất kỳ phương pháp cụ thể nào. Trong thực tế, tôi có thể dễ dàng hình dung mã định hướng thủ tục trong một mô hình MVC (đó là những gì tôi cảm thấy như bạn đang ngụ ý).

Vì vậy, tôi nghĩ rằng câu hỏi thực sự là; có phải chúng ta dễ bị mã thủ tục hơn khi sử dụng mẫu MVC.

(và có lẽ tôi sẽ chỉ nhận được một số phiếu bầu?)

Không chống, nhưng OOP cũng không bắt buộc đối với MVC.

Bởi vì các bộ điều khiển, thường được đại diện bởi classess không có dữ liệu. Đối với các chức năng thuần túy sẽ đủ.

Nếu bạn đi xa hơn và tách dữ liệu khỏi hành vi, ví dụ, giả sử rằng các mô hình chỉ hoạt động trên dữ liệu cơ sở dữ liệu mà chúng tìm nạp mỗi khi chức năng của chúng (chịu trách nhiệm thao tác dữ liệu) được gọi (thay vì lưu trữ một số loại dữ liệu trong ví dụ các trường) - sau đó bạn có thể nói tương tự cho các mô hình.

Đi xa hơn, nếu bạn lấy lớp xem của một ứng dụng và chia nó theo cách tương tự, bạn thực sự sẽ kết thúc bằng kết luận rằng MVC không liên quan gì đến OOP và hoàn toàn có thể viết triển khai MVC mà không gặp bất kỳ khó khăn nào khi chỉ sử dụng phương pháp tiếp cận thủ tục .

Trong Ý kiến ​​của tôi, OOP có một nhược điểm là vì (dữ liệu và hành vi) được đúc thành một thực thể (Lớp), điều này cho thấy hiệu ứng ghép nhiều hơn so với sự gắn kết. Mặt khác, MVC có Mô hình chứa ... (Đậu, DAO, Các lớp logic khác), Trình điều khiển chỉ định cách điều khiển phải di chuyển và Chế độ xem để xác định cách hiển thị dữ liệu theo cách riêng biệt. Dựa trên điều này, không có vấn đề gì nếu dự án quá lớn để chuẩn bị có thể dễ dàng được thực hiện như một thực thể riêng biệt ngoài việc bị lẫn lộn không giống như OOP. Vấn đề được giải quyết theo mô hình logic giống như chia chiến lược chinh phục và MVC hoàn toàn tuân theo điều này.