Phần 7. Giới thiệu mẫu MVC (Model-View-Controller)

Tài liệu này là một phần của loạt bài "Giới thiệu về Phát triển Doanh nghiệp". Các bài viết trước:

• về mạng
• về kiến ​​trúc phần mềm
• về HTTP/HTTPS
• về những điều cơ bản của Maven
• về servlet (viết một ứng dụng web đơn giản)
• về thùng chứa servlet

Trong bài viết này, chúng ta sẽ tìm hiểu về một thứ gọi là MVC. Chúng ta sẽ nói về MVC là gì, chạm vào lịch sử của nó, khám phá các ý tưởng và khái niệm cơ bản được thể hiện trong MVC, xem xét từng bước cách chia ứng dụng thành các mô-đun Model, View và Controller, viết một ứng dụng web nhỏ sử dụng Spring Boot và sử dụng Spring MVC làm ví dụ, xem cách dữ liệu được gửi từ mã Java tới các trang HTML. Để hiểu về vật liệu này, bạn cần phải làm quen với các mẫu thiết kế, đặc biệt là quan sát viên và mặt đứng. Và làm quen với các yêu cầu và phản hồi HTTP, hiểu kiến ​​thức cơ bản về HTML và biết chú thích Java là gì. Lấy một tách cà phê và đồ ăn nhẹ, và cảm thấy thoải mái. Hãy bắt đầu nào.

Lịch sử của MVC

Những ý tưởng đằng sau MVC được Trygve Reenskaug xây dựng khi làm việc tại Xerox PARC vào cuối những năm 1970. Vào thời đó, làm việc với máy tính đòi hỏi phải có bằng cấp và liên tục nghiên cứu tài liệu đồ sộ. Nhiệm vụ được giải quyết bởi Reenskaug cùng với một nhóm các nhà phát triển rất mạnh là đơn giản hóa sự tương tác của người dùng thông thường với máy tính. Cần phải tạo ra các công cụ, một mặt, cực kỳ đơn giản và dễ hiểu, mặt khác, giúp điều khiển máy tính và các ứng dụng phức tạp. Reenskaug làm việc trong một nhóm phát triển máy tính xách tay "dành cho trẻ em ở mọi lứa tuổi" — Dynabook, cũng như ngôn ngữ SmallTalk dưới sự lãnh đạo của Alan Kay. Đó là khi các khái niệm về giao diện thân thiện được đặt ra. Xét về nhiều mặt, công việc do Reenskaug và nhóm của ông thực hiện đã ảnh hưởng đến sự phát triển của lĩnh vực CNTT. Đây là một thực tế thú vị không áp dụng trực tiếp cho MVC, nhưng minh họa tầm quan trọng của những phát triển này. Alan Kaynói"Khi tôi lần đầu tiên đến Apple, vào năm 84, máy Mac đã ra mắt và Newsweek đã liên lạc với tôi và hỏi tôi nghĩ gì về máy Mac. Tôi nói, 'Chà, máy Mac là máy tính cá nhân đầu tiên đủ tốt để bị chỉ trích.' Vì vậy, sau khi công bố iPhone vào năm 2007, anh ấy đã mang nó đến và đưa cho tôi và nói: 'Alan, cái này đã đủ tốt để bị chỉ trích chưa?' Và tôi đã nói, 'Steve, hãy làm cho nó to như một chiếc máy tính bảng và anh sẽ thống trị thế giới.'" Sau 3 năm, vào ngày 27 tháng 1 năm 2010, Apple giới thiệu iPad với đường chéo 9,7 inch. Nói cách khác, Steve Jobs đã làm theo lời khuyên của Alan Kay gần như chính xác. Dự án của Reenskaug kéo dài 10 năm. Nhưng ấn phẩm đầu tiên về MVC đã xuất hiện sau 10 năm nữa. Martin Fowler, tác giả của nhiều cuốn sách và bài viết về kiến ​​trúc phần mềm, đề cập rằng anh ấy đã nghiên cứu MVC bằng phiên bản Smalltalk đang hoạt động. Bởi vì không có thông tin về MVC từ nguồn ban đầu trong một thời gian dài và vì một số lý do khác, một số lượng lớn các cách hiểu khác nhau về khái niệm này đã xuất hiện. Do đó, nhiều người coi MVC là một mẫu thiết kế. Ít phổ biến hơn, MVC được gọi là mẫu tổng hợp hoặc sự kết hợp của một số mẫu hoạt động cùng nhau để tạo ra các ứng dụng phức tạp. Tuy nhiên, như đã đề cập trước đó, MVC thực sự chủ yếu là một tập hợp các ý tưởng/nguyên tắc/phương pháp tiếp cận kiến ​​trúc có thể được triển khai theo nhiều cách khác nhau bằng cách sử dụng các mẫu khác nhau... Tiếp theo, chúng ta sẽ xem xét các ý tưởng chính được nhúng trong khái niệm MVC. và vì một số lý do khác, một số lượng lớn các cách giải thích khác nhau về khái niệm này đã xuất hiện. Do đó, nhiều người coi MVC là một mẫu thiết kế. Ít phổ biến hơn, MVC được gọi là mẫu tổng hợp hoặc sự kết hợp của một số mẫu hoạt động cùng nhau để tạo ra các ứng dụng phức tạp. Tuy nhiên, như đã đề cập trước đó, MVC thực sự chủ yếu là một tập hợp các ý tưởng/nguyên tắc/phương pháp tiếp cận kiến ​​trúc có thể được triển khai theo nhiều cách khác nhau bằng cách sử dụng các mẫu khác nhau... Tiếp theo, chúng ta sẽ xem xét các ý tưởng chính được nhúng trong khái niệm MVC. và vì một số lý do khác, một số lượng lớn các cách giải thích khác nhau về khái niệm này đã xuất hiện. Do đó, nhiều người coi MVC là một mẫu thiết kế. Ít phổ biến hơn, MVC được gọi là mẫu tổng hợp hoặc sự kết hợp của một số mẫu hoạt động cùng nhau để tạo ra các ứng dụng phức tạp. Tuy nhiên, như đã đề cập trước đó, MVC thực sự chủ yếu là một tập hợp các ý tưởng/nguyên tắc/phương pháp tiếp cận kiến ​​trúc có thể được triển khai theo nhiều cách khác nhau bằng cách sử dụng các mẫu khác nhau... Tiếp theo, chúng ta sẽ xem xét các ý tưởng chính được nhúng trong khái niệm MVC.

MVC: Ý tưởng và nguyên tắc cơ bản

• VC là một tập hợp các ý tưởng và nguyên tắc kiến ​​trúc để xây dựng các hệ thống thông tin phức tạp với giao diện người dùng
• MVC là từ viết tắt của: Model-View-Controller

Tuyên bố miễn trừ trách nhiệm: MVC không phải là mẫu thiết kế. MVC là một tập hợp các ý tưởng và nguyên tắc kiến ​​trúc để xây dựng các hệ thống phức tạp với giao diện người dùng. Nhưng để thuận tiện, để không phải nói đi nói lại "một tập hợp các ý tưởng kiến ​​trúc...", chúng ta sẽ đề cập đến mẫu MVC. Hãy bắt đầu với sự đơn giản. Điều gì ẩn đằng sau các từ Model-View-Controller? Khi sử dụng mẫu MVC để phát triển hệ thống có giao diện người dùng, bạn cần chia hệ thống thành ba thành phần. Chúng cũng có thể được gọi là mô-đun hoặc thành phần. Gọi cho họ những gì bạn muốn, nhưng chia hệ thống thành ba thành phần. Mỗi thành phần có mục đích riêng của nó. Người mẫu. Thành phần/mô-đun đầu tiên được gọi là mô hình. Nó chứa tất cả logic nghiệp vụ của ứng dụng. Xem.Phần thứ hai của hệ thống là chế độ xem. Module này chịu trách nhiệm hiển thị dữ liệu cho người dùng. Mọi thứ mà người dùng nhìn thấy đều do chế độ xem tạo ra. Bộ điều khiển.Liên kết thứ ba trong chuỗi này là bộ điều khiển. Nó chứa mã chịu trách nhiệm xử lý các hành động của người dùng (tất cả các hành động của người dùng được xử lý trong bộ điều khiển). Mô hình là phần độc lập nhất của hệ thống. Độc lập đến mức nó không được biết gì về các mô-đun khung nhìn và bộ điều khiển. Mô hình độc lập đến mức các nhà phát triển của nó có thể hầu như không biết gì về khung nhìn và bộ điều khiển. Mục đích chính của khung nhìn là cung cấp thông tin từ mô hình ở định dạng mà người dùng có thể sử dụng. Hạn chế chính của khung nhìn là nó không được thay đổi mô hình theo bất kỳ cách nào. Mục đích chính của bộ điều khiển là xử lý các hành động của người dùng. Người dùng thực hiện các thay đổi đối với mô hình thông qua bộ điều khiển. Hay chính xác hơn là dữ liệu được lưu trữ trong mô hình. Đây là sơ đồ bạn đã thấy trước đây trong bài học: Từ tất cả những điều này, chúng ta có thể rút ra một kết luận hợp lý. Một hệ thống phức tạp cần được chia thành các mô-đun. Hãy mô tả ngắn gọn các bước để đạt được sự tách biệt này.

Bước 1. Tách logic nghiệp vụ của ứng dụng khỏi giao diện người dùng

Ý tưởng chính của MVC là bất kỳ ứng dụng nào có giao diện người dùng đều có thể được chia thành 2 mô-đun: mô-đun chịu trách nhiệm triển khai logic nghiệp vụ và giao diện người dùng. Mô-đun đầu tiên sẽ thực hiện chức năng chính của ứng dụng. Mô-đun này là cốt lõi của hệ thống, nơi triển khai mô hình miền của ứng dụng. Trong mô hình MVC, mô-đun này là chữ M, tức là mô hình. Mô-đun thứ hai triển khai toàn bộ giao diện người dùng, bao gồm logic để hiển thị dữ liệu cho người dùng và xử lý tương tác của người dùng với ứng dụng. Mục tiêu chính của sự tách biệt này là để đảm bảo rằng cốt lõi của hệ thống ("mô hình" trong thuật ngữ MVC) có thể được phát triển và thử nghiệm độc lập. Sau khi thực hiện việc tách này, kiến ​​trúc của ứng dụng trông như thế này:

Bước 2 Sử dụng mẫu quan sát để làm cho mô hình độc lập hơn và đồng bộ hóa giao diện người dùng

Ở đây chúng tôi có 2 mục tiêu:

1. Đạt được sự độc lập thậm chí còn lớn hơn cho mô hình
2. Đồng bộ hóa giao diện người dùng

Ví dụ sau đây sẽ giúp bạn hiểu ý nghĩa của việc đồng bộ hóa giao diện người dùng. Giả sử chúng ta đang mua vé xem phim trực tuyến và xem số lượng ghế còn trống trong rạp. Đồng thời, người khác có thể mua vé xem phim. Nếu người này mua vé trước chúng tôi, chúng tôi muốn thấy số lượng ghế có sẵn cho thời gian chiếu mà chúng tôi đang xem xét giảm xuống. Bây giờ hãy nghĩ xem điều này có thể được thực hiện như thế nào trong một chương trình. Giả sử chúng ta có lõi hệ thống (mô hình của chúng ta) và giao diện (trang web để mua vé). Hai người dùng đang cố gắng chọn một chỗ ngồi trong rạp cùng một lúc. Người dùng đầu tiên mua vé. Trang web cần hiển thị cho người dùng thứ hai rằng điều này đã xảy ra. Làm thế nào là điều này phải xảy ra? Nếu chúng tôi cập nhật giao diện từ lõi, sau đó lõi (mô hình của chúng tôi) sẽ phụ thuộc vào giao diện. Khi chúng tôi phát triển và thử nghiệm mô hình, chúng tôi sẽ phải ghi nhớ các cách khác nhau để cập nhật giao diện. Để đạt được điều này, chúng ta cần triển khai mẫu quan sát viên. Mẫu này cho phép mô hình gửi thông báo thay đổi tới tất cả người nghe. Với tư cách là người nghe sự kiện (hoặc người quan sát), giao diện người dùng sẽ nhận được thông báo và được cập nhật. Một mặt, mẫu người quan sát cho phép mô hình thông báo cho giao diện (khung nhìn và bộ điều khiển) rằng những thay đổi đã xảy ra mà không thực sự biết bất cứ điều gì về nó, do đó vẫn độc lập. Mặt khác, nó giúp đồng bộ hóa giao diện người dùng. chúng ta cần triển khai mẫu quan sát viên. Mẫu này cho phép mô hình gửi thông báo thay đổi tới tất cả người nghe. Với tư cách là người nghe sự kiện (hoặc người quan sát), giao diện người dùng sẽ nhận được thông báo và được cập nhật. Một mặt, mẫu người quan sát cho phép mô hình thông báo cho giao diện (khung nhìn và bộ điều khiển) rằng những thay đổi đã xảy ra mà không thực sự biết bất cứ điều gì về nó, do đó vẫn độc lập. Mặt khác, nó giúp đồng bộ hóa giao diện người dùng. chúng ta cần triển khai mẫu quan sát viên. Mẫu này cho phép mô hình gửi thông báo thay đổi tới tất cả người nghe. Với tư cách là người nghe sự kiện (hoặc người quan sát), giao diện người dùng sẽ nhận được thông báo và được cập nhật. Một mặt, mẫu người quan sát cho phép mô hình thông báo cho giao diện (khung nhìn và bộ điều khiển) rằng những thay đổi đã xảy ra mà không thực sự biết bất cứ điều gì về nó, do đó vẫn độc lập. Mặt khác, nó giúp đồng bộ hóa giao diện người dùng.

Bước 3 Tách giao diện thành chế độ xem và bộ điều khiển

Chúng tôi tiếp tục chia ứng dụng thành các mô-đun, nhưng bây giờ ở cấp độ thấp hơn trong hệ thống phân cấp. Ở bước này, giao diện người dùng (mà chúng ta đã tách thành một mô-đun riêng biệt ở bước 1) được chia thành dạng xem và bộ điều khiển. Vẽ một đường thẳng giữa khung nhìn và bộ điều khiển là khó khăn. Nếu chúng ta nói rằng khung nhìn là những gì người dùng nhìn thấy và bộ điều khiển là cơ chế cho phép người dùng tương tác với hệ thống, bạn có thể chỉ ra một mâu thuẫn. Các thành phần điều khiển, chẳng hạn như các nút trên trang web hoặc bàn phím ảo trên màn hình điện thoại, về cơ bản là một phần của bộ điều khiển. Nhưng chúng hiển thị với người dùng như bất kỳ phần nào của chế độ xem. Điều chúng ta đang thực sự nói đến ở đây là sự tách biệt chức năng. Nhiệm vụ chính của giao diện người dùng là tạo điều kiện cho người dùng tương tác với hệ thống.

• xuất và hiển thị thông tin hệ thống thuận tiện cho người dùng
• nhập dữ liệu và lệnh của người dùng (giao tiếp với hệ thống)

Các chức năng này xác định cách chia giao diện người dùng thành các mô-đun. Cuối cùng, kiến ​​trúc hệ thống trông như thế này: Và đây là cách chúng ta đến với một ứng dụng bao gồm ba mô-đun được gọi là mô hình, khung nhìn và bộ điều khiển. Hãy tóm tắt:

1. Theo các nguyên tắc của mô hình MVC, một hệ thống phải được chia thành các mô-đun.
2. Mô-đun độc lập và quan trọng nhất phải là mô hình.
3. Mô hình là cốt lõi của hệ thống. Có thể phát triển và thử nghiệm nó một cách độc lập với giao diện người dùng.
4. Để đạt được điều này, trong bước phân chia đầu tiên, chúng ta cần chia hệ thống thành mô hình và giao diện người dùng.
5. Sau đó, bằng cách sử dụng mẫu người quan sát, chúng tôi củng cố tính độc lập của mô hình và đồng bộ hóa giao diện người dùng.
6. Bước thứ ba là chia giao diện người dùng thành bộ điều khiển và chế độ xem.
7. Tất cả những gì cần thiết để nhận dữ liệu người dùng vào hệ thống đều nằm trong bộ điều khiển.
8. Tất cả những gì cần thiết để cung cấp thông tin cho người dùng đều có trong chế độ xem.

Chỉ còn một điều quan trọng nữa cần thảo luận trước khi bạn có thể uống sô cô la nóng.

Một chút về cách view và controller tương tác với model

Bằng cách nhập thông tin thông qua bộ điều khiển, người dùng thay đổi mô hình. Hoặc ít nhất, người dùng thay đổi dữ liệu mô hình. Khi người dùng nhận thông tin thông qua các phần tử giao diện (thông qua khung nhìn), người dùng đang nhận thông tin về mô hình. Làm thế nào để điều này xảy ra? Chế độ xem và bộ điều khiển tương tác với mô hình bằng cách nào? Xét cho cùng, các lớp của khung nhìn không thể gọi trực tiếp các phương thức của các lớp trong mô hình để đọc/ghi dữ liệu. Nếu không, chúng ta sẽ không thể nói rằng mô hình này là độc lập. Mô hình là một tập hợp các lớp có liên quan chặt chẽ mà cả chế độ xem và bộ điều khiển đều không có quyền truy cập. Để kết nối mô hình với khung nhìn và bộ điều khiển, chúng ta cần triển khai mẫu thiết kế mặt tiền. Mặt tiền của mô hình là lớp giữa mô hình và giao diện người dùng, qua đó khung nhìn nhận dữ liệu được định dạng thuận tiện và Bộ điều khiển thay đổi dữ liệu bằng cách gọi các phương thức cần thiết trên mặt tiền. Cuối cùng, mọi thứ trông như thế này:

MVC: Chúng ta đạt được gì?

Mục tiêu chính của mô hình MVC là tách biệt việc triển khai logic nghiệp vụ (mô hình) khỏi trực quan hóa (khung nhìn). Sự tách biệt này làm tăng khả năng tái sử dụng mã. Lợi ích của MVC thể hiện rõ nhất khi chúng ta cần trình bày cùng một dữ liệu ở các định dạng khác nhau. Ví dụ: dưới dạng bảng, biểu đồ hoặc biểu đồ (sử dụng các dạng xem khác nhau). Đồng thời, không ảnh hưởng đến cách triển khai chế độ xem, chúng tôi có thể thay đổi cách chúng tôi phản hồi với hành động của người dùng (nhấp vào nút, nhập dữ liệu). Nếu tuân theo các nguyên tắc của MVC, bạn có thể đơn giản hóa quá trình phát triển phần mềm, tăng khả năng đọc mã cũng như cải thiện khả năng mở rộng và khả năng bảo trì. Trong bài viết cuối cùng của loạt bài "Giới thiệu về phát triển doanh nghiệp", chúng ta sẽ xem xét triển khai MVC được xây dựng bằng Spring MVC. Phần 8. Hãy viết một ứng dụng nhỏ bằng Spring Boot