Design Pattern | MVC Pattern
Chào mừng bạn đã đồng hành cùng mình đến bài viết này, cho đến nay, chúng ta đã tìm hiểu các mẫu thiết kế Creational, Structurall và Behavioral. Trong bài viết này, bạn sẽ tìm hiểu về MCV Pattern.
Đây là một mẫu được xây dựng dựa trên các mẫu thiết kế mà bạn đã tìm hiểu trong các bài viết vừa qua, từ giờ, bạn cũng sẽ tìm hiểu về một số nguyên tắc thiết kế chung dựa trên các mẫu thiết kế để đạt được phần mềm có thể tái sử dụng, linh hoạt và có thể bảo trì. Sau đó, bạn sẽ tìm hiểu sang cách phân tích và phê bình mã của bạn cho thiết kế Bad Design, bạn sẽ tìm hiểu về nhiều sơ xuất phổ biến khiến lý do vì sao chúng dẫn đến thiết kế xấu, trong ngành Công nghệ phần mềm, những thứ này được gọi là AntiPattern, hoặc Code Smells.
Mình thường bắt đầu buổi sáng với bài River flow in you. Còn bạn ? Hãy bắt đầu nào.
Hãy tưởng tượng bạn được thuê một cửa hàng tạp hóa nhỏ trong khu phố của bạn. Nhân viên thu ngân của họ đang phàn nàn về các hệ thống tiền mặt kiểu cũ, nơi họ phải gõ giá vào của từng món hàng. Đồng thời, khách hàng cũng bắt đầu mệt mỏi vì phải xếp hàng chờ mua hàng quá lâu. Những gì họ cần là một hệ thống nhập và hiển thị các đơn hàng, nói cách khác, một giao diện người dùng (User Interface). Khách hàng và nhân viên thu ngân sẽ thấy các mặt hàng được nhập vào đơn hàng bằng máy quét mã vạch. Họ cũng có thể nhìn thấy tổng số tiền hóa đơn, nhân viên thu ngân sẽ thích nó, vì họ không phải gõ giá từng sản phẩm nữa. Và khách hàng cũng sẽ thích, vì đơn hàng được thực hiện nhanh hơn và họ có thể nhìn thấy giá trên bề mặt màn hình. Nếu mắc lỗi, nhân viên thu ngân có thể dễ dàng sửa chữa và mọi người đều vui vẻ. Bất cứ khi nào bạn nghe thấy giao diện người dùng (User Interface), bạn nên xem xét sử dụng MCV Pattern.
MVC viết tắt của Model View Controler, phân chia trách nhiệm của một hệ thống cung cấp giao diện người dùng thành ba thành phần đó.
Hãy xem sơ đồ UML đơn giản, đầu tiền, hãy nói về mô hình (Model). Model chứa các dữ liệu được gạch chân và logic người dùng muốn xem và thao tác. Trong trường hơp này, nhân viên thu ngân và khách hàng muốn có thể đặt các đơn hàng tạp hóa, một phần quan trọng của MVC Pattern là mô hình này được khép kín, nó tất cả trạng thái, phương thức và dữ liệu khác mà nó cần tồn tại. Điểm dừng tiếp theo là chế độ xem (View). Nó cung cấp cho người dùng cách xem Model hoặc ít nhất là một phần của nó. Tại cửa hàng tạp hóa, đây sẽ là màn hình hiển thị danh sách mặt hàng và giá của chúng. Đôi khi, the view cũng sẽ có các yếu tố tương tác như các nút bấm, và trường cho phép người dùng tương tác với hệ thống, vâng, Model như là backend, phần mềm cơ bản, View như là lớp trình bày, tất cả được sử dụng trong cùng một mô hình. Khi một số giá trị thay đổi ở backend, nó phải báo cho View để tự cập nhật cho phù hợp, điều này được sử dụng bằng Observer Design Pattern. Hãy nhớ rằng, trong mẫu thiết kế đó, người quan sát hành động như người đăng ký, trong trường hợp này, bất kỳ góc nhìn nào cũng là một người quan sát, khi Model thay đổi, nó thông báo cho tất cả View được đăng ký vào nó, the view có thể có cách để người dùng thay đổi trong Model cơ bản.
Nếu bạn là nhân viên thu ngân tại cửa hàng tạp hóa, bạn có thể thay đổi thứ tự bằng cách nào ? Chà, bạn có thể xóa các mặt hàng nếu khách hàng thay đổi ý định hoặc thay đổi giá của mặt hàng để chỉnh sửa. Bạn có thể đã thấy các nút bấm cho hành động này ở siêu thị, trong MVC Pattern, The View không trực tiếp gửi yêu cầu đến The Model, thay vào đó, thông tin về tương tác người dùng chuyển đến bộ điều khiển (controler) chịu trách nhiệm diễn giải các yêu cầu thay đổi Model. Bằng cách này, The View chỉ chịu trách nhiệm cho sự xuất hiện trực quan của hệ thống và mô hình(Model) chỉ tập trung vào việc quản lý thông tin cho hệ thống.
Do đó, MVC Pattern về cơ bản sử dụng nguyên tắc phân tách mối quan tâm thiết kế để phân chia các trách nhiệm chính và hệ thống tương tác. Nói chung, model tương ứng với các đối tượng thực thể có nguồn gốc từ việc phân tích không gian vấn đề cho hệ thống.
Hãy nghĩ về các nhân viên ở cửa hàng tạp hóa, model có thể rất phức tạp, nên hãy sử dụng một phiên bản đơn giản hóa. Model đặt hàng của cửa hàng chỉ đơn giản là một danh sách thực phẩm với giá cả và một vài phương pháp để thay đổi thứ tự, View sẽ hiển thị danh sách các mặt hàng với giá của chúng và tổng giá, nhân vân thu ngân cũng muốn có thể sửa chữa sai lầm, vì vậy, hãy bao gồm 2 nút chúng ta vừa nói đến, xóa mục và thay đổi giá. Nhân viên thu ngân nhất nút thay đổi giá, một bộ xử lý sự kiện cho nút này gọi bộ điều khiển (controler). Bộ điều khiển đọc giá mới từ trường văn bản trên chế độ xem và sử dụng hai thông tin này, mục thay đổi và giá mới để yêu cầu thay đổi giá trong Model bằng phương thức trong Model. Bộ điều khiển cũng có thể kiểm tra xem giá có hợp lệ không và yêu cầu khung nhìn(the view) xóa hộp văn bản, Model hiện đã thay đổi giá của một mặt hàng, vì The View là Observer của Model, nên Model sẽ thông báo cho chế độ xem rằng nó đã thay đổi và The view (chế độ xem) tự cập nhật, màn hình của nhân viên hiển thị giá mới.
Vậy, implement như thế nào ? Hãy bắt đầu với phần thiết yếu nhất, Model. Mô hình có thể tồn tại mà không cần The View, Controler, tất nhiên, bạn có thể sử dụng các View để xem và thay đổi Model, nhưng Model không nên dựa vào một View hoặc Controller để tồn tại, vì quan điểm của chúng ta sẽ là một người quan sát, chúng ta phải làm cho Model không thể quan sát được.
Chúng ta sẽ sử dụng Java.util để thực hiện hành vi này, Java.util chứa một lớp Observable mà bạn có thể extends. Nếu bạn nhập Java.util và sau đó extends observable, lớp StoreOrder của bạn sẽ cho phép bạn thêm The View của mình dưới dạng quan sát viên. Bằng cách đó, họ sẽ hành động như những người đăng ký đơn hàng và cập nhật bất cứ khi nào đơn hàng được cập nhật.
Lớp này có một phương thức tự sửa đổi, bạn có thể thêm các mục, xóa và thay đổi giá. Tất nhiên, model order thực tế có thể có nhiều hơn, nhưng những chức năng cơ bản như thế này là một khởi đầu tốt, lưu ý rằng model của chúng ta không có bất kỳ thành phần giao diện sử dụng nào và không biết bất kỳ về The View nào. Nó sẽ tự cập nhật View thông qua Observer Pattern bất cứ khi nào thay đổi được thực hiện, phương thức setChanged() sẽ đánh dấu sự thay đổi, và phương thức notifyobservers() thông báo cho The View để chúng có thể tự cập nhật.
Tiếp theo sẽ đến lớp View:
Vì lớp OrderView thực hiện Observer Interface, bạn phải cung cấp và cập nhật phương thức.
Trong ví dụ này, Controller rất đơn giản, nhưng vẫn còn vài điều chúng ta có thể học, bộ điều khiển phải có cả tham chiếu đến tất cả các View và Model mà nó kết nối. Điều quan trọng, bộ điều khiển không thực hiện thay đổi trạng thái của Model trực tiếp, nó gọi phương thức của mô hình để thực hiện các thay đổi. Sử dụng controller, giúp mã tốt hơn theo một số cách. Trình bày giao diện người dùng, bộ điều khiển có trách nhiệm diễn giải đầu vào của người dùng và làm việc với Model dựa trên đầu vào đó. Việc tách các mối quan tâm này làm cho mã sạch hơn và dễ sửa đổi hơn. Thứ hai, với bộ điều khiển ở giữa Model và View, View không còn gắn chặ với Model, trong khi bạn phát triển, bạn có thể thêm các tính năng cho mô hình và kiểm tra chúng trước khi đưa chúng vào View.
Giống như các mẫu thiết kế khác, không có cách nào để sử dụng hoàn toàn MVC Pattern, bạn có thể thấy rằng chương trình của bạn cần một chút tiếp cận khác. Tính năng của MVC là tách biệt mối quan tâm giữa backend, frontend và sự phối hợp giữa hai loại. Trong khi ví dụ của họ có một lớp cho Model, View, và Controller. Các hệ thống phần mềm thường có nhiều lớp Model, xen các lớp View và các lớp Controller. Bạn sẽ thấy MVC trong bất kỳ dự án nào có giao diện người dùng.
Hãy cùng xem lại các thành phần. Model chứa dữ liệu cơ bản, trạng thái và logic mà người dùng muốn xem và thao tác. View trình bày thông tin mô hình cho người dùng theo cách họ mong đợi và cho phép tương tác với nó. Một Model có thể có một số View thể hiện các phần khác nhau của Model hoặc trình bày mô hình theo các cách khác nhau và bộ điều khiển diễn giải sự tương tác của người dùng với các thành phần trong View và tự sửa đổi Model. Controller đảm bảo rằng, các View mà Model được ghép lỏng lẻo và cho phép View chủ yếu liên quan đến các mối quan tâm về giao diện người dùng. Việc tách các chức năng này làm cho mã dễ dàng phát triển, dễ đọc và bảo trì hơn.
Sự tách biệt mối quan tâm này cho phép chương trình của họ được module hóa và kết nối lỏng lẻo. Khớp nối lỏng lẻo (Loose coupling) đặc biệt quan trọng trong các nhóm phát triển lớn. Một nhóm các nhà phát triển có thể đang làm việc ở frontend, backend, hoặc các Model trong khi một nhóm khác làm ở ngược lại.
Ngay cả khi bạn tự code một dự án, việc tách riêng chúng sẽ cho phép bạn tập trung vào từng nhóm trách nhiệm một cách riêng biệt. Bạn có thể dễ dàng thay thế các View để sử dụng bộ giao diện người dùng khác trong khi vẫn giữ nguyên mô hình.
Cảm ơn. Chào buổi sáng, và bây giờ đã là gần buổi trưa.
Đây là một mẫu được xây dựng dựa trên các mẫu thiết kế mà bạn đã tìm hiểu trong các bài viết vừa qua, từ giờ, bạn cũng sẽ tìm hiểu về một số nguyên tắc thiết kế chung dựa trên các mẫu thiết kế để đạt được phần mềm có thể tái sử dụng, linh hoạt và có thể bảo trì. Sau đó, bạn sẽ tìm hiểu sang cách phân tích và phê bình mã của bạn cho thiết kế Bad Design, bạn sẽ tìm hiểu về nhiều sơ xuất phổ biến khiến lý do vì sao chúng dẫn đến thiết kế xấu, trong ngành Công nghệ phần mềm, những thứ này được gọi là AntiPattern, hoặc Code Smells.
Mình thường bắt đầu buổi sáng với bài River flow in you. Còn bạn ? Hãy bắt đầu nào.
Hãy tưởng tượng bạn được thuê một cửa hàng tạp hóa nhỏ trong khu phố của bạn. Nhân viên thu ngân của họ đang phàn nàn về các hệ thống tiền mặt kiểu cũ, nơi họ phải gõ giá vào của từng món hàng. Đồng thời, khách hàng cũng bắt đầu mệt mỏi vì phải xếp hàng chờ mua hàng quá lâu. Những gì họ cần là một hệ thống nhập và hiển thị các đơn hàng, nói cách khác, một giao diện người dùng (User Interface). Khách hàng và nhân viên thu ngân sẽ thấy các mặt hàng được nhập vào đơn hàng bằng máy quét mã vạch. Họ cũng có thể nhìn thấy tổng số tiền hóa đơn, nhân viên thu ngân sẽ thích nó, vì họ không phải gõ giá từng sản phẩm nữa. Và khách hàng cũng sẽ thích, vì đơn hàng được thực hiện nhanh hơn và họ có thể nhìn thấy giá trên bề mặt màn hình. Nếu mắc lỗi, nhân viên thu ngân có thể dễ dàng sửa chữa và mọi người đều vui vẻ. Bất cứ khi nào bạn nghe thấy giao diện người dùng (User Interface), bạn nên xem xét sử dụng MCV Pattern.
MVC viết tắt của Model View Controler, phân chia trách nhiệm của một hệ thống cung cấp giao diện người dùng thành ba thành phần đó.
Hãy xem sơ đồ UML đơn giản, đầu tiền, hãy nói về mô hình (Model). Model chứa các dữ liệu được gạch chân và logic người dùng muốn xem và thao tác. Trong trường hơp này, nhân viên thu ngân và khách hàng muốn có thể đặt các đơn hàng tạp hóa, một phần quan trọng của MVC Pattern là mô hình này được khép kín, nó tất cả trạng thái, phương thức và dữ liệu khác mà nó cần tồn tại. Điểm dừng tiếp theo là chế độ xem (View). Nó cung cấp cho người dùng cách xem Model hoặc ít nhất là một phần của nó. Tại cửa hàng tạp hóa, đây sẽ là màn hình hiển thị danh sách mặt hàng và giá của chúng. Đôi khi, the view cũng sẽ có các yếu tố tương tác như các nút bấm, và trường cho phép người dùng tương tác với hệ thống, vâng, Model như là backend, phần mềm cơ bản, View như là lớp trình bày, tất cả được sử dụng trong cùng một mô hình. Khi một số giá trị thay đổi ở backend, nó phải báo cho View để tự cập nhật cho phù hợp, điều này được sử dụng bằng Observer Design Pattern. Hãy nhớ rằng, trong mẫu thiết kế đó, người quan sát hành động như người đăng ký, trong trường hợp này, bất kỳ góc nhìn nào cũng là một người quan sát, khi Model thay đổi, nó thông báo cho tất cả View được đăng ký vào nó, the view có thể có cách để người dùng thay đổi trong Model cơ bản.
Nếu bạn là nhân viên thu ngân tại cửa hàng tạp hóa, bạn có thể thay đổi thứ tự bằng cách nào ? Chà, bạn có thể xóa các mặt hàng nếu khách hàng thay đổi ý định hoặc thay đổi giá của mặt hàng để chỉnh sửa. Bạn có thể đã thấy các nút bấm cho hành động này ở siêu thị, trong MVC Pattern, The View không trực tiếp gửi yêu cầu đến The Model, thay vào đó, thông tin về tương tác người dùng chuyển đến bộ điều khiển (controler) chịu trách nhiệm diễn giải các yêu cầu thay đổi Model. Bằng cách này, The View chỉ chịu trách nhiệm cho sự xuất hiện trực quan của hệ thống và mô hình(Model) chỉ tập trung vào việc quản lý thông tin cho hệ thống.
Do đó, MVC Pattern về cơ bản sử dụng nguyên tắc phân tách mối quan tâm thiết kế để phân chia các trách nhiệm chính và hệ thống tương tác. Nói chung, model tương ứng với các đối tượng thực thể có nguồn gốc từ việc phân tích không gian vấn đề cho hệ thống.
Hãy nghĩ về các nhân viên ở cửa hàng tạp hóa, model có thể rất phức tạp, nên hãy sử dụng một phiên bản đơn giản hóa. Model đặt hàng của cửa hàng chỉ đơn giản là một danh sách thực phẩm với giá cả và một vài phương pháp để thay đổi thứ tự, View sẽ hiển thị danh sách các mặt hàng với giá của chúng và tổng giá, nhân vân thu ngân cũng muốn có thể sửa chữa sai lầm, vì vậy, hãy bao gồm 2 nút chúng ta vừa nói đến, xóa mục và thay đổi giá. Nhân viên thu ngân nhất nút thay đổi giá, một bộ xử lý sự kiện cho nút này gọi bộ điều khiển (controler). Bộ điều khiển đọc giá mới từ trường văn bản trên chế độ xem và sử dụng hai thông tin này, mục thay đổi và giá mới để yêu cầu thay đổi giá trong Model bằng phương thức trong Model. Bộ điều khiển cũng có thể kiểm tra xem giá có hợp lệ không và yêu cầu khung nhìn(the view) xóa hộp văn bản, Model hiện đã thay đổi giá của một mặt hàng, vì The View là Observer của Model, nên Model sẽ thông báo cho chế độ xem rằng nó đã thay đổi và The view (chế độ xem) tự cập nhật, màn hình của nhân viên hiển thị giá mới.
Vậy, implement như thế nào ? Hãy bắt đầu với phần thiết yếu nhất, Model. Mô hình có thể tồn tại mà không cần The View, Controler, tất nhiên, bạn có thể sử dụng các View để xem và thay đổi Model, nhưng Model không nên dựa vào một View hoặc Controller để tồn tại, vì quan điểm của chúng ta sẽ là một người quan sát, chúng ta phải làm cho Model không thể quan sát được.
Chúng ta sẽ sử dụng Java.util để thực hiện hành vi này, Java.util chứa một lớp Observable mà bạn có thể extends. Nếu bạn nhập Java.util và sau đó extends observable, lớp StoreOrder của bạn sẽ cho phép bạn thêm The View của mình dưới dạng quan sát viên. Bằng cách đó, họ sẽ hành động như những người đăng ký đơn hàng và cập nhật bất cứ khi nào đơn hàng được cập nhật.
Lớp này có một phương thức tự sửa đổi, bạn có thể thêm các mục, xóa và thay đổi giá. Tất nhiên, model order thực tế có thể có nhiều hơn, nhưng những chức năng cơ bản như thế này là một khởi đầu tốt, lưu ý rằng model của chúng ta không có bất kỳ thành phần giao diện sử dụng nào và không biết bất kỳ về The View nào. Nó sẽ tự cập nhật View thông qua Observer Pattern bất cứ khi nào thay đổi được thực hiện, phương thức setChanged() sẽ đánh dấu sự thay đổi, và phương thức notifyobservers() thông báo cho The View để chúng có thể tự cập nhật.
Tiếp theo sẽ đến lớp View:
Vì lớp OrderView thực hiện Observer Interface, bạn phải cung cấp và cập nhật phương thức.
Trong ví dụ này, Controller rất đơn giản, nhưng vẫn còn vài điều chúng ta có thể học, bộ điều khiển phải có cả tham chiếu đến tất cả các View và Model mà nó kết nối. Điều quan trọng, bộ điều khiển không thực hiện thay đổi trạng thái của Model trực tiếp, nó gọi phương thức của mô hình để thực hiện các thay đổi. Sử dụng controller, giúp mã tốt hơn theo một số cách. Trình bày giao diện người dùng, bộ điều khiển có trách nhiệm diễn giải đầu vào của người dùng và làm việc với Model dựa trên đầu vào đó. Việc tách các mối quan tâm này làm cho mã sạch hơn và dễ sửa đổi hơn. Thứ hai, với bộ điều khiển ở giữa Model và View, View không còn gắn chặ với Model, trong khi bạn phát triển, bạn có thể thêm các tính năng cho mô hình và kiểm tra chúng trước khi đưa chúng vào View.
Giống như các mẫu thiết kế khác, không có cách nào để sử dụng hoàn toàn MVC Pattern, bạn có thể thấy rằng chương trình của bạn cần một chút tiếp cận khác. Tính năng của MVC là tách biệt mối quan tâm giữa backend, frontend và sự phối hợp giữa hai loại. Trong khi ví dụ của họ có một lớp cho Model, View, và Controller. Các hệ thống phần mềm thường có nhiều lớp Model, xen các lớp View và các lớp Controller. Bạn sẽ thấy MVC trong bất kỳ dự án nào có giao diện người dùng.
Hãy cùng xem lại các thành phần. Model chứa dữ liệu cơ bản, trạng thái và logic mà người dùng muốn xem và thao tác. View trình bày thông tin mô hình cho người dùng theo cách họ mong đợi và cho phép tương tác với nó. Một Model có thể có một số View thể hiện các phần khác nhau của Model hoặc trình bày mô hình theo các cách khác nhau và bộ điều khiển diễn giải sự tương tác của người dùng với các thành phần trong View và tự sửa đổi Model. Controller đảm bảo rằng, các View mà Model được ghép lỏng lẻo và cho phép View chủ yếu liên quan đến các mối quan tâm về giao diện người dùng. Việc tách các chức năng này làm cho mã dễ dàng phát triển, dễ đọc và bảo trì hơn.
Sự tách biệt mối quan tâm này cho phép chương trình của họ được module hóa và kết nối lỏng lẻo. Khớp nối lỏng lẻo (Loose coupling) đặc biệt quan trọng trong các nhóm phát triển lớn. Một nhóm các nhà phát triển có thể đang làm việc ở frontend, backend, hoặc các Model trong khi một nhóm khác làm ở ngược lại.
Ngay cả khi bạn tự code một dự án, việc tách riêng chúng sẽ cho phép bạn tập trung vào từng nhóm trách nhiệm một cách riêng biệt. Bạn có thể dễ dàng thay thế các View để sử dụng bộ giao diện người dùng khác trong khi vẫn giữ nguyên mô hình.
Cảm ơn. Chào buổi sáng, và bây giờ đã là gần buổi trưa.
Nhận xét
Đăng nhận xét