Giải thích Trình điều khiển Chế độ xem Mô hình

Kinh nghiệm của tôi về việc phát triển các trang web động chủ yếu giới hạn ở các máy chủ Java. Tôi đã sử dụng Tomcat để phát triển các máy chủ Java khác nhau và tôi không ngần ngại nói rằng tôi thành thạo một cách hợp lý với công nghệ này, cũng như với HTML / CSS / Javascript phía máy khách cho giao diện người dùng.

Khi tôi nghĩ "trang web động", tôi nghĩ: người dùng yêu cầu URL có chuỗi truy vấn, máy chủ nhận được truy vấn và sau đó tiến hành xuất HTML một cách linh hoạt để trả lời truy vấn. Điều này thường liên quan đến giao tiếp với cơ sở dữ liệu để lấy dữ liệu được yêu cầu để hiển thị. Về cơ bản, đây là ý tưởng đằng sau doGetphương thức của Java HttpServlet.

Nhưng những ngày này, tôi đang nghe nhiều hơn về các khung mới hơn như Django và Ruby on Rails, tất cả đều tận dụng kiến ​​trúc "Trình điều khiển Chế độ xem Mô hình". Tôi đã đọc nhiều bài viết giải thích về MVC, nhưng tôi thực sự gặp khó khăn trong việc hiểu các lợi ích. Tôi hiểu rằng ý tưởng chung là tách logic kinh doanh khỏi logic UI, nhưng tôi không thấy điều này thực sự khác biệt như thế nào so với lập trình web thông thường. Về bản chất, lập trình web buộc bạn phải tách biệt logic nghiệp vụ (lập trình phía máy chủ phía sau) khỏi lập trình UI (HTML phía máy khách hoặc Javascript), vì cả hai tồn tại trong các lĩnh vực lập trình hoàn toàn khác nhau.

Câu hỏi: MVC cung cấp cái gì trên một thứ như Java servlet và quan trọng hơn, chính xác là MVC là gì và nó khác với những gì bạn thường làm để phát triển một trang web động bằng cách sử dụng một cách tiếp cận truyền thống hơn như Java servlet (hoặc thậm chí một cái gì đó cũ hơn như CGI)? Nếu có thể, khi giải thích về MVC, vui lòng cung cấp một ví dụ minh họa cách MVC được áp dụng cho quy trình phát triển web và cách nó có lợi.

Đầu tiên tôi nghĩ là nói tốt nhất về Kiến trúc MVC là gì và sau đó đi sâu hơn vào cách bạn đang lập trình.

Kiến trúc MVC là cách để tổ chức luồng công việc bên trong một sistem sotfware, hãy nghĩ về nó như một cách phân lớp để thực hiện hành vi hệ thống. Các lớp này là:

1. Mô hình : Đại diện cho Mô hình Dữ liệu của bạn, lõi của hệ thống nơi tất cả thông tin liên quan đến mô hình đó phải được bản địa hóa. Vì vậy, ví dụ: nếu bạn định chơi một trò chơi, bạn sẽ cần Người chơi, Quy tắc, Chướng ngại vật và một số logic liên quan đến tương tác của các yếu tố này, chẳng hạn như: Người chơi sẽ có thể sắp xếp Trở ngại khi áp dụng một số Quy tắc.

   Các mẫu là suy nghĩ đầu tiên bạn nên nghĩ ra vì nó sẽ là trung tâm của các ứng dụng của bạn .

2. Người điều khiển : Đây là nơi phép màu xảy ra và là nơi Kiến trúc lớp gặp gỡ Mô hình hướng đối tượng mà nó dự định sử dụng. Đây là nơi bạn thực hiện cách hệ thống phản ứng khi một số người dùng ứng dụng yêu cầu một cái gì đó về ứng dụng giao diện người dùng.

   Bộ điều khiển phải có khả năng xử lý các Đối tượng mô hình, thực hiện các thao tác với chúng để đạt được những gì người dùng yêu cầu và sau đó ủy thác kết quả cho Lớp xem tương ứng để hiển thị lại cho người dùng của chúng tôi.

3. Chế độ xem : Đây là Điểm bắt đầu và Điểm kết thúc của tương tác Người dùng. Đây là nơi bạn xác định cách người dùng tương tác với ứng dụng. Ngày nay, người dùng khá phổ biến cố gắng truy cập, ví dụ, các ứng dụng web từ các loại phương tiện khác nhau như: Điện thoại di động, Bàn, Máy tính, Máy tính xách tay, v.v.

   Nói chung, mỗi techonologie cần một ngôn ngữ khác nhau để tạo chế độ xem, vì vậy hãy tưởng tượng rằng Mô hình Dữ liệu của bạn và cách mô hình đó tương tác và cách bạn kết xuất các tương tác đó đều được mã hóa cứng, hoàn toàn không có cách nào để sử dụng lại mã của bạn theo cách không phải là CopyPaste . Kết quả là mã có mùi và rất nhiều thời gian lãng phí để thích ứng với hệ thống HOLE.

   Ưu điểm của việc có Chế độ xem trong một lớp riêng biệt, cho phép chúng tôi làm việc độc lập với Mô hình mà chúng tôi hiện đang làm việc . Chúng ta chỉ cần biết làm thế nào chúng ta sẽ hiển thị danh sách các đối tượng mà bộ điều khiển đang gửi cho chúng ta. Làm thế nào anh ta tạo ra nó là hoàn toàn tầm thường

Vì vậy, cuối cùng chúng tôi đã có một Mô hình độc lập có thể được điều chỉnh khi chúng tôi thấy phù hợp với nhu cầu hiện tại của chúng tôi (hôm nay tôi cần xử lý Trò chơi Monouser không có quy tắc, ngày mai tôi sẽ chơi với bạn bè và bây giờ là Multiuser của nó, v.v.) điều đó không phụ thuộc vào cách chúng ta sẽ kết xuất nó cho người dùng. Sau đó, Bộ điều khiển nắm bắt yêu cầu của người dùng xuất phát từ chế độ xem, xử lý Đối tượng mô hình và sau đó đưa thông tin trở lại Chế độ xem để hiển thị nó.

Quay lại câu hỏi đầu tiên bạn đã hỏi: Giống như bạn có thể thấy (tôi hy vọng) MVC là CÁCH để thực hiện mọi việc chứ không phải là CÔNG NGHỆ để tạo ra phần mềm. Bạn có thể sử dụng java Servlets của mình và triển khai Kiến trúc MVC theo nó.

Dưới đây là trang web ví dụ Q & A sử dụng Kiến trúc MVC để làm rõ một chút

Để trả lời câu hỏi của bạn

What does MVC offer over something like a Java servlet

MVC là một mô hình, không phải là một công nghệ. Vì vậy, mẫu có thể được áp dụng khi bạn đang lập trình với Servlets.

Hãy để tôi thử giải thích mô hình MVC với chính Servlets. Vì vậy, những gì bạn đang cố gắng làm khi bạn nói về việc áp dụng MVC là, tách riêng Mô hình (logic nghiệp vụ), khung nhìn (logic trình bày) và Bộ điều khiển (Bộ điều khiển Servlet ủy quyền điều khiển cho logic nghiệp vụ phù hợp).

Trong trường hợp này, MVC không chỉ tách rời doanh nghiệp khỏi lớp trình bày và lớp trình điều khiển, mà lớp doanh nghiệp thậm chí không biết rằng có một trình điều khiển hoặc bản trình bày tồn tại.

Các khung công tác chính trong Java như Struts theo mô hình này. Tôi nghĩ rằng bạn có khái niệm sai. Bạn có thể đọc thêm về nó trên internet.

MVC thực sự dễ hiểu, nó chỉ là một mẫu thiết kế, tuy nhiên, tôi đã thấy rằng khó khăn nhất / giám sát là phần Model.

• Model : Dữ liệu của bạn (không phải là cơ sở dữ liệu của riêng bạn!, Mô hình thậm chí có thể là tệp ini hoặc xml hoặc dữ liệu từ dịch vụ web). Các lớp mô hình phục vụ mục đích xác định, lắp ráp và xử lý dữ liệu. Đọc bài viết xuất sắc có tên " M trong MVC: Tại sao các mô hình bị hiểu sai và không được đánh giá cao ". Mô hình chỉ nên được truy cập bởi bộ điều khiển.
• Lượt xem : Mã GUI (trình bày) của bạn. Chỉ nên truy cập bộ điều khiển
• Điều khiển : logic của bạn. Xử lý giao tiếp giữa mô hình và xem.

Các MVC khái niệm này là không có gì mới. Nó bắt đầu với Smalltalk khoảng năm 1979.

Về cốt lõi, MVC là một cách để tổ chức các trách nhiệm của mã của bạn sao cho nó có tính mô đun, có thể dự đoán và mạnh mẽ.

Sự tách biệt cho phép bạn các quyền tự do sau:

• Khả năng phát triển mô hình mà không ảnh hưởng đến logic ứng dụng hoặc hiển thị dữ liệu
• Khả năng thay đổi logic kinh doanh mà không ảnh hưởng đến mô hình (nghĩa là thêm các bước mới, v.v.)
• Khả năng đại diện cho mô hình theo nhiều cách khác nhau

Nếu cẩn thận, bạn có khả năng có thể thiết kế mô hình và bộ điều khiển để bạn có thể thay thế hoàn toàn ứng dụng máy tính để bàn bằng ứng dụng web làm giao diện người dùng.

Gần đây, cách tiếp cận Ruby on Rails đối với MVC đã giới thiệu một số khái niệm mới hơn được sao chép trong hầu hết các khung ứng dụng web theo phong cách MVC. Điều này bao gồm các khái niệm "Quy ước về cấu hình", hành động của bộ điều khiển ánh xạ tới các phương thức lớp và định tuyến các yêu cầu URL tới mã bên dưới.