Trong tài liệu này, chúng tôi sẽ giới thiệu cho bạn một thứ như MVC. Hãy nói về MVC là gì, tìm hiểu về lịch sử hình thành của nó, hiểu các ý tưởng và khái niệm chính vốn có trong MVC, xem xét từng bước cách chia một ứng dụng thành các mô-đun Model, View, Controller, đồng thời viết một ứng dụng web nhỏ trong Spring-Boot và Sử dụng Spring-MVC làm ví dụ, hãy xem cách dữ liệu được chuyển từ mã Java sang trang html. Để hiểu được tài 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à Observer và Facade. Làm quen với các yêu cầu và phản hồi HTTP, hiểu những điều cơ bản về html, biết chú thích là gì trong Java. Ngồi lại, pha trà, chuẩn bị món tráng miệng, salad, món chính và món đầu tiên. Chúng tôi bắt đầu.
Lịch sử của MVC
Ý tưởng về MVC được Trygve Reenskaug hình thành khi làm việc tại Xerox PARC vào cuối những năm 70. Vào thời đó, không thể làm việc với máy tính nếu không có bằng cấp học thuật và thường xuyên nghiên cứu lượng tài liệu đồ sộ. Vấn đề mà Reenskaug đã giải quyết 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 bình 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 quản lý máy tính và các ứng dụng phức tạp. Reenskaug làm việc trong nhóm phát triển máy tính di động "dành cho trẻ em mọi lứa tuổi" - Dynabook, cũng như ngôn ngữ SmallTalk dưới sự chỉ đạo của Alan Kay. Chính tại thời điểm đó, các khái niệm về giao diện thân thiện đã được đặt ra. Công việc của Reenskaug với nhóm của ông đã ảnh hưởng rất lớn đến sự phát triển của lĩnh vực CNTT. Hãy để chúng tôi trình bày một sự thật thú vị không liên quan trực tiếp đến MVC nhưng minh họa tầm quan trọng của những phát triển đó. Năm 2007, sau buổi giới thiệu iPhone của Apple, Alan Kay đã nói: “Khi Macintosh ra mắt, Newsweek đã hỏi tôi nghĩ gì về nó. Tôi đã nói: đây là chiếc máy tính cá nhân đầu tiên đáng bị chỉ trích. Sau bài thuyết trình, Steve Jobs bước tới và hỏi: iPhone có đáng bị chỉ trích không? Và tôi nói, hãy làm nó dài 5 x 8 inch và bạn sẽ chinh phục được thế giới.” Ba năm sau, vào ngày 27 tháng 1 năm 2010, Apple giới thiệu iPad 9,7 inch. Tức là Steve Jobs đã làm theo lời khuyên của Alan Kay gần như theo đúng nghĩa đen. Dự án mà Rennskaug thực hiện kéo dài 10 năm. Và ấn phẩm đầu tiên về MVC từ những người tạo ra nó đã được xuất bản thêm 10 năm sau đó. Martin Fowler, tác giả của một số cuốn sách và bài viết về kiến trúc phần mềm, đề cập rằng ông đã học MVC từ phiên bản hoạt động của SmallTalk. Do không có thông tin về MVC từ nguồn chính trong một thời gian dài, cũng như vì một số lý do khác, nên đã xuất hiện một số lượng lớn các cách hiểu khác nhau về khái niệm này. Kết quả là nhiều người coi MVC là một sơ đồ hoặc 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 để triển khai các ứng dụng phức tạp. Nhưng trên thực tế, như đã nói trước đó, MVC chủ yếu là một tập hợp các ý tưởng/nguyên tắc/phương pháp 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 nhiều mẫu khác nhau... Tiếp theo, chúng ta sẽ cố gắng xem xét các ý tưởng chính được nhúng trong khái niệm MVC.
MVC là gì: ý tưởng và nguyên tắc cơ bản
VC là 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 có 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 chính xác 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 lặp lại nhiều lần: “Một tập hợp các ý tưởng kiến trúc…”, chúng ta sẽ gọi MVC là một mẫu. Hãy bắt đầu với một cái gì đó đơn giản. Điều gì ẩn sau dòng chữ Model-View-Controller? Khi phát triển hệ thống có giao diện người dùng, theo mô hình MVC, bạn cần chia hệ thống thành ba thành phần. Đến lượt chúng, chúng có thể được gọi là mô-đun hoặc thành phần. Nói những gì bạn muốn, nhưng chia cho ba. Mỗi thành phần sẽ có mục đích riêng. 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à khung nhìn. Mô-đun này có nhiệm vụ hiển thị dữ liệu cho người dùng. Mọi thứ người dùng nhìn thấy đều được tạo bởi chế độ xem. Người điều khiển. Liên kết thứ ba trong chuỗi này là bộ điều khiển. Nó lưu trữ mã chịu trách nhiệm xử lý các hành động của người dùng (mọi hành động của người dùng trong hệ thống đều đượ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 nên biết gì về các mô-đun View và Controller. Mô hình này độ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ề Chế độ xem và Bộ điều khiển. Mục đích chính của Chế độ xem là cung cấp thông tin từ Mô hình ở định dạng thân thiện với người dùng. Hạn chế chính của Chế độ xem 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. Thông qua Bộ điều khiển, người dùng thực hiện các thay đổi đối với mô hình. Chính xác hơn là vào dữ liệu được lưu trữ trong mô hình. Hãy để chúng tôi cung cấp lại sơ đồ đã được trình bày cho bạn trong bài giảng: Từ tất cả những điều này, chúng ta có thể rút ra một kết luận hoàn toàn hợp lý. Một hệ thống phức tạp cần được chia thành các mô-đun. Chúng ta hãy mô tả ngắn gọn các bước làm thế nào để đạt được sự tách biệt như vậ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ột mô-đun chịu trách nhiệm triển khai logic nghiệp vụ của ứng dụng và giao diện người dùng. Mô-đun đầu tiên sẽ triển khai chức năng chính của ứng dụng. Mô-đun này sẽ là cốt lõi của hệ thống, trong đó mô hình miền ứng dụng được triển khai. Trong khái niệm MVC, mô-đun này sẽ là chữ cái M của chúng tôi, tức là người mẫu. Mô-đun thứ hai sẽ triển khai toàn bộ giao diện người dùng, bao gồm hiển thị dữ liệu cho người dùng và logic tương tác của người dùng với ứng dụng. Mục đích chính của sự tách biệt này là để đảm bảo rằng phần cốt lõi của hệ thống (Mô hình theo thuật ngữ MVC) có thể được phát triển và thử nghiệm một cách độc lập. Kiến trúc ứng dụng sau khi phân chia như vậy sẽ như sau:
Bước 2. Sử dụng mẫu Observer, đạt được tính độc lập cao hơn nữa của mô hình cũng như đồng bộ hóa giao diện người dùng
Ở đây chúng tôi theo đuổi 2 mục tiêu:
Đạt được sự độc lập lớn hơn của mô hình.
Đồ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 mua vé xem phim trực tuyến và xem số ghế còn trống trong rạp. Người khác có thể mua vé xem phim cùng lúc với chúng tôi. Nếu người này mua vé trước chúng ta, chúng ta muốn thấy rằng số chỗ trống cho phiên của chúng ta đã giảm đi. Bây giờ hãy nghĩ xem làm thế nào điều này có thể được thực hiện bên trong 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 nơi chúng ta mua hàng). Trên trang web, 2 người dùng đồng thời chọn chỗ ngồi. Người dùng đầu tiên đã mua một vé. Người dùng thứ hai cần hiển thị thông tin này trên trang. Làm thế nào điều này nên xảy ra? Nếu chúng ta cập nhật giao diện từ kernel hệ thống thì kernel, mô hình của chúng ta sẽ phụ thuộc vào giao diện. Khi phát triển và thử nghiệm mô hình, bạn sẽ phải ghi nhớ nhiều cách khác nhau để cập nhật giao diện. Để đạt được điều này, bạn cần triển khai mẫu Observer. Với sự trợ giúp của nó, mô hình sẽ gửi thông báo về những thay đổi đến tất cả người đăng ký. Giao diện, là một người đăng ký như vậy, sẽ nhận được thông báo và cập nhật. Mẫu Observer một mặt cho phép mô hình thông báo cho giao diện (chế độ xem và bộ điều khiển) rằng những thay đổi đã xảy ra trong đó, mặt khác, thực sự “không biết” gì về chúng và do đó vẫn độc lập. Mặt khác, điều này sẽ cho phép giao diện người dùng được đồng bộ hóa.
Bước 3. Chia giao diện thành View và Controller
Chúng tôi tiếp tục chia ứng dụng thành các mô-đun, nhưng ở cấp độ phân cấp thấp hơn. Ở bước này, giao diện người dùng (đã được tách thành một mô-đun riêng ở bước 1) được chia thành dạng xem và bộ điều khiển. Thật khó để vẽ một ranh giới chặt chẽ giữa chế độ xem và bộ điều khiể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ế mà qua đó người dùng có thể tương tác với hệ thống thì có một số mâu thuẫn. Các nút đ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 cũng hiển thị với người dùng như bất kỳ phần nào của chế độ xem. Ở đây chúng ta đang nói nhiều hơn về phân chia chức năng. Nhiệm vụ chính của giao diện người dùng là đảm bảo sự tương tác của người dùng với hệ thống. Điều này có nghĩa là giao diện chỉ có 2 chức năng:
hiển thị và hiển thị thuận tiện các thông tin về hệ thống tới người dùng;
nhập dữ liệu và lệnh của người dùng vào hệ thống (truyền lên hệ thống);
Các chức năng này xác định cách chia giao diện thành các mô-đun. Kết quả là kiến trúc hệ thống trông như thế này: Vì vậy, chúng ta có một ứng dụng gồm ba mô-đun gọi là Model, View và Controller. Để tóm tắt:
Theo nguyên tắc của MVC, hệ thống cần được chia thành các mô-đun.
Mô-đun quan trọng và độc lập nhất phải là mô hình.
Mô hình là cốt lõi của hệ thống. Bạn cần có khả năng phát triển và thử nghiệm nó một cách độc lập với giao diện.
Để làm được điều này, ở bước đầu tiên của việc phân tách hệ thống, bạn cần chia nó thành mô hình và giao diện.
Tiếp theo, bằng cách sử dụng mẫu Observer, chúng tôi củng cố tính độc lập của mô hình và đạt được sự đồng bộ hóa giao diện người dùng.
Bước thứ ba là chia giao diện thành bộ điều khiển và khung nhìn.
Tất cả những gì cần thiết để nhập thông tin từ người dùng vào hệ thống đều vào bộ điều khiển.
Tất cả những thông tin đầu ra từ hệ thống tới người dùng đều được hiển thị.
Còn một điều quan trọng nữa cần bàn và bạn có thể uống ca cao.
Một chút về mối quan hệ giữa View với Controller và Model
Khi người dùng nhập thông tin thông qua bộ điều khiển, anh ta sẽ thực hiện các thay đổi đối với mô hình. Ít nhất người dùng thực hiện thay đổi dữ liệu mô hình. Khi người dùng nhận thông tin thông qua các thành phần giao diện (thông qua Chế độ xem), người dùng sẽ nhận được thông tin về dữ liệu mô hình. Làm thế nào điều này xảy ra? View và Controller tương tác với mô hình như thế nào? Rốt cuộc, các lớp View không thể trực tiếp sử dụng các phương thức của các lớp Model để đọc/ghi dữ liệu, nếu không thì không thể có bất kỳ câu hỏi nào về tính độc lập của Model. Mô hình đại diện cho một tập hợp các lớp được liên kết chặt chẽ với nhau mà theo cách tốt, 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 Chế độ xem và Bộ điều khiển, cần phải triển khai mẫu thiết kế Mặt tiền. Mặt tiền mô hình sẽ là lớp giữa Mô hình và giao diện, qua đó Chế độ xem nhận dữ liệu ở đị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 mặt tiền cần thiết. Theo sơ đồ, cuối cùng, mọi thứ sẽ như thế này:
MVC: lợi ích là gì?
Mục tiêu chính của việc tuân theo các nguyên tắc MVC là tách biệt việc triển khai logic nghiệp vụ (mô hình) của ứng dụng khỏi trực quan hóa (chế độ xem) của nó. Sự tách biệt này sẽ làm tăng khả năng sử dụng lại mã. Lợi ích của việc sử dụng MVC thể hiện rõ ràng nhất trong trường hợp người dùng cần cung cấp cùng một dữ liệu dưới nhiều hình thức khác nhau. Ví dụ: ở dạng bảng, biểu đồ hoặc biểu đồ (sử dụng các loại khác nhau). Đồng thời, không ảnh hưởng đến việc thực hiện chế độ xem, bạn có thể thay đổi phản ứng đố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 bạn tuân theo các nguyên tắc của MVC, bạn có thể đơn giản hóa việc viết chương trình, tăng khả năng đọc mã và giúp mở rộng và bảo trì hệ thống trong tương lai dễ dàng hơn. Trong tài liệu 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 việc triển khai MVC bằng Spring-MVC làm ví dụ. Phần 8. Viết một ứng dụng nhỏ trong spring-boot
Từ tất cả những điều này, chúng ta có thể rút ra một kết luận hoàn toàn hợp lý. Một hệ thống phức tạp cần được chia thành các mô-đun. Chúng ta hãy mô tả ngắn gọn các bước làm thế nào để đạt được sự tách biệt như vậy.
Vì vậy, chúng ta có một ứng dụng gồm ba mô-đun gọi là Model, View và Controller. Để tóm tắt:
GO TO FULL VERSION