Một số công nghệ áp dụng kiến trúc MODEL - VIEW - CONTROLLER

Tiếp đến, Reenskaug mô tả các yêu cầu tổng quát mà một framework cần có để có thể xây dựng các hệ thống mới trên nền một hệ thống đã có, phù hợp với cái đã có và hệ thống mới có đủ tính

D A N H M Ụ C C Á C H ÌN H VẼ T R O N G LU Ậ N V Ă N 5

MỜ Đ Ằ Ư 6

C H Ư Ơ N G I T Ồ N G Q U A N V Ề M V C 9

1.1 L ịch sử phát triển của M V C 9

1.2 Thiết kế theo m ô hình m ẫu (design p a tte rn ) 12

1.2.1 Đ ịnh n g h ĩa 12

1.2.2 Lợi ích củ a thiết kế theo m ô hình m ẫ u 12

1.2.3 Phân loại các m ầu thiết k ế 13

1.3 K iến trúc M V C 14

1.3.1 M odel (M ô hình dừ liệ u ) 14

1.3.2 V iew (H iền thị hay giao diện người d ù n g ) 15

1.3.3 C ontroller (Đ iều khiển hay Q uán lý chứ c n ă n g ) 15

1.3.4 Sự tư ơng tác giữa các thành phần cù a M V C 16

1.3.5 M ột số đ ặc điểm cơ bản của M V C 17

1.4 M ột số các m ẫu thiết kế trong M V C 18

1.4.1 C o m posite P atte rn 18

1.4.2 O bserver P a tte r n 20

1.4.3 Strategy P a t t e r n 21

1.4.4 A dapter P a tte rn 23

1.4.5 C om m and P a tte rn 24

1.4.6 Factory P a tte rn 26

1.4.7 M ediator P a tte r n 27

1.4.8 D eco rato r P a tte rn 28

1.4.9 So sánh các m ẫu thiết k ế 29

1.5 G iới thiệu m ột số công nghệ nền tả n g 31

1.5.1 H T T P, H T M L và các sự k iệ n 31

1.5.2 C hu trình req u est/resp o n se (hỏi/đáp) của H T T P 32

1.5.3 C ác phiên làm việc (S e ss io n ) 32

1.5 4 X M L 33

1.5.5 N gôn ng ừ Jav a và các ứng dụng F ra m e w o rk 34

1.5.6 J a v a B e a n s 34

1.5.7 J a v a S e r v le t 35

1.5.8 B ộ lọc th ô n g t i n 36

1.5.9 Di chuyển các yêu c ầ u 36

1.5.10 Jav a S erv er P age, T aglib, Java S erv er F a c e 37

1.5.11 C ác m e ssa g e -re so u rc e !37

C H Ư Ơ N G II Á P D Ự N G M V C T R O N G T H IẾ T K É G IA O D IỆ N Đ Ô H Ọ A 39

Một số công nghệ áp dụng kiến trúc Model - View - Controller

II 1 G iới t h i ệ u 39

11.2 Áp d ụ n g M V C tro n g ngôn ngữ lập trìn h S m a llT a lk 39

11.2.1 G iới t h i ệ u 39

11.2.2 T hành p h ận M o d e l 40

11.2.3 T hành p h ậ n V i e w 42

11.2.4 T hậnh p h ầ n C o n tro lle r 44

11.2.4 Phối h ợ p c á c th àn h phần tro n g M V C 45

11.3 Áp d ụ n g M V C tro n g thiết kế các thành p h ần Jav a S w in g 46

11.3.1 G iới t h i ệ u 46

11.3.3 Jav a S w in g và th iế t kế M V C 48

11.3.3.1 T hành phận M o d e l 49

11.3.3.2 T hành ph ần giao d iệ n 51

11.3.4 M ột ví dụ v ề S w in g 53

C H Ư Ơ N G III Á P D Ự N G M V C T R O N G CÁ C Ứ N G D Ụ N G W E B 57

III 1 L ựa chọn k iến trú c tổng thể cho m ột ứ ng d ụ n g 57

111.2 Á p dụng M V C tro n g m ột ứng dụng w eb tổng q u á t 59

111.2.1 X ây d ự n g th àn h phần C o n tr o lle r 59

111.2.1.1 X ác đ ịn h phirơng thứ c xử lý y êu c ầ u 59

111.2.1.2 C h u y ề n yêu cầu người dùng ch o chứ c năn g xử lý 60

111.2.1.3 L ự a c h ọ n tra n g m àn hình hiển thị tiếp th e o 62

111.2.1.4 Đ a đ iều k h i ể n 66

111.2.2 X ây d ự n g th àn h phần V ie w 68

III.2.2.1 T hiết kế m ẫu cho m àn hình hiển th ị 68

Ịn 2 2 2 Á nh x ạ U R L tới m ột trang m àn hình hiển t h ị 70

111.2.3 X ây d ự n g th àn h phần M o d e l 71

111.3 Á p d ụng M V C tro n g công nghệ J2E E củ a S u n 73

111.3.1 G iới th iệu v ề cô n g nghệ J 2 E E 73

111.3.2 T hành p h ầ n V ie w 73

111.3.3 T hành p h ầ n M o d e l 74

111.3.4 T hành p h ầ n C o n tr o lle r 76

111.3.5 Tirơng tác giữ a các thành phần M V C 78

111.4 Á p dụng M V C tro n g Struts F ra m e w o rk 80

111.4.1 G iới th iệu về S truts F ra m e w o rk 80

in 4 2 T hành p h ầ n M o d e l 81

111.4.3 T hành p h ầ n V ie w 82

111.4.4 T hành p h ầ n C o n tr o lle r 82

111.4.5 Phối h ợ p các thành phần M V C 82

111.5 Á p dụng M V C tro n g ngôn ngữ lập trình P H P 85

in 5 1 G iới th iệ u v ề P H P 85

111.5.2 X ây d ự n g th àn h phần M o d e l 86

M ột số công nghệ áp (lụng kiến trúc M odel - View - Controller

111.5.3 X ây dựng th àn h phận V ie w 89

111.5.4 X âỵ dự ng th àn h phần C o n tr o lle r 91

111.5.5 P hối hợp c ác thành ph ần M V C 92

C H Ư Ơ N G IV X Â Y D ự N G H Ệ T H Ố N G ISP B IL L IN G SY ST E M TR ÊN STR U TS F R A M E W O R K 94

IV 1 Đ ặt bài t o á n 94

IV 2 Sơ đồ chức năn g hệ th ố n g 95

IV 3 T hiết kế C S D L 97

IV 4 G iao diện ch ư ơ n g t r i n h 98

IV 5 X ây dự ng các thành phần ứng d ụ n g 100

IV 5.1 X ây dựng thành phận M o d e l 100

IV 5.2 X ây dựng thành phận V ie w 101

IV 5.3 X ây dựng thành phần C o n tro lle r 103

IV 6 Đ ánh giá kết quà và hướng phát triể n 104

K ÉT L U Ậ N 105

TÀJ L IỆ U T H A M K H Ả O 106

P H Ụ LỤ C 107

Một sổ công nghệ áp dụng kiến trúc Model - View - Controller

DANH MỤC CÁC HỈNH VẼ TRONG LUẬN VĂN

Hình 1.3.3 C ác thành phần M odel, View, Controller trong thanh cuộnHình 1.3.4 Sự tương tác giữa các thành phần của M VC

Hình 1.4.2 C ác cách hiển thị khác nhau của cùng một dữ liệu

H ình 1.5.2 C h u trình hỏi/đáp (req u est/resp o n se) cùa H T T P

Hình II.3.1 Kiến trúc Java Foundation C lasses

Hình II.3.2 Kiến trúc tách M odel trong Java Swing

Hình II.3.4 G iao diện chương trình Toolbar Example

Hình III.2.1.3 a Lược đồ lựa chọn màn hình hiển thị tiếp theo

Hình III.2.1.3 b Lược đồ lựa chọn màn hình hiển thị đăng xuất

Hình III.2.1.4 Sơ đồ Đơn điều khiển

Hình III.2.1.4.b Sơ đồ Đa điều khiển

Hình III.2.1 4.C Sơ đồ Đa điều khiển kết hợp Router

Hình III.2.2.1 Bố cục mẫu của một trang web

Hình II 1.3.5 Lược đồ cấu trúc một ứng dụng w eb trên kiến trúc J2EEHỉnh III.5.4 M ô hình UML

Hình IV 1 Mô hình hoạt động của hệ thổng ISP Billing System

Hình IV 3 Sơ đồ phân rã chức năng hệ thống ISP Billing SystemHình IV.2 Sơ đồ quan hệ thực thể của chức năng Sercurity

Hình IV.4.a G iao diện Đăng nhập hệ thống

Hình IV 4.b G iao diện thêm mới một Admin

Hình IV.4.C G iao diện Danh sách các Admin

Hình IV.4 d Giao diện Cập nhật thông tin Admin

Một số công nghệ áp dụng kiến trúc Model - View - Controller

MỞ ĐÀUPhân tích và thiết kế là khâu đầu tiên và có ý nghĩa quyết định cho sự :hành công của hệ thống phần mềm được xây dựng Các yêu cầu chủ yếu đổi với một phần mềm tốt như: tính có thể bào trì được, độ tin cậy cao, tính mềm đèo, có giao diện sứ dụng thích hợp được quyết định trước hết ở giai đoạn phân tích và thiết kế Một thống kê trước đây cho thấy: một lỗi trong phân tích hệ thống bị bò qua, khi thiết kế xong mới phát hiện thì chi phí sừa chữa lăng lên 10 lần; và nếu bị bỏ qua cho đến khi cài đặt mới phát hiện ra thì chi phí tăng lên 40 lần; nếu đến khi vận hành mới phát hiện ra thì chi phí sửa chữa lên tới 90 lần M ặt khác, chi phí cho khâu phân tích và thiết kế phần mềm ờ các nước phát triển (như Mỹ, Anh, Ấn Đ ộ ) có thể lên đến trên 30% tồng chi phí phát triển phần mềm Trong khi đó, chi phí cho khâu lập trình có

dự án đã giảm xuống dưới 10% Điều này cho thấy vai trò cùa phân tích và thiết kế phần mềm ngày càng trở nên quan trọng, nhất là trong điều kiện các

hệ thống phần mềm ngày càng có quy mô lớn và độ phức tạp ngày càng cao, các công cụ lập trình ngày càng phong phú và tiện lợi

Trong những năm gần đây, thiết kế theo mô hình mẫu nổi lên như một lĩnh vực mới mẻ được các nhà khoa học quan tâm nghiên cứu bời tính ứng dụng cao trong lĩnh vực thiết kế phần mềm Với hàng loạt các nghiên cứu, đề xuất được thử nghiệm và ứng dụng thành công vào các sàn phẩm công nghệ cao đã chứng minh thiết kế theo mô hình mẫu là lĩnh vực nghiên cứu có nền tàng lý thuyết vững chắc Thiết kế theo mô hình mẫu được ứng dụng trong rất nhiều khâu của quá trình thiết kế một ứng dụng Từ việc lựa chọn kiến trúc tồng thể của ứng dụng cho tới thiết kế tương tác bên trong mỗi thành phần con của hệ thống

M odel - V iew - Controller (M V C) là một mẫu thiết kế phần mềm

Một số công nghệ áp dụng kiến trúc Model - View - Controller

cược đánh giá là một trong những phương pháp thiết kế hướng đối tượng tìành công nhất hiện nay M V C đà được nhiều nhà khoa học tìm hiểu, nghiên cứu và đã thu được nhiều thành công lớn.

Với một lĩnh vực khoa học công nghệ mới còn nhiều triển vọng trong tirơng lai, em đã chọn hướng nghiên cứu về “ M ột số công nghệ áp dụng kiến trúc Model - View - C ontroller” cho luận văn của mình Luận văn này được xày dựng và tổng hợp các nội dung dựa trên nền một số nghiên cứu về thiết

kế theo mô hình mầu m à trọng tâm là kiến trúc M V C của các nhà nghiên cứu tiong những năm gần đây và rất nhiều các bài báo được công bố trên các tạp chí chuyên nghành cũng như trên Internet

Nội dung của luận văn gồm các chương m ục sau:

C h ư ơ n g I : T ổ n g q u a n v ề M V C

Chương này trình bày những nét khái quát nhất về kiến trúc M odel - View - Controller bao gồm các kiến thức về lịch sử phát triền của M VC, về thiết kế theo mô hình mầu, các thành phần trong M V C, sự tương tác giữa các thành phần M odel, View, Controller và một số các mẫu thiết kế cơ bản để tạo thành kiến trúc M VC

C h ư ơ n g I I : Á p d ụ n g M V C tr o n g c á c ứ n g d ụ n g đ ỗ h ọ a

Trong chương này trình bày về việc áp dụng M V C trong việc xây dựng các ứng dụng đồ họa bao gồm việc áp dụng M V C trong ngôn ngữ lập trình SmallTalk và việc áp dụng M VC trong các thành phần của Java Swing

C h ư ơ n g I I I : Á p d ụ n g k iế n tr ú c M V C t r o n g c á c ứ n g d ụ n g w eb

Chương này trình bày về cách thức áp dụng kiến trúc M VC trong các ưng dụng web nói chung bao gồm các kiến thức về việc lựa chọn mô hình tổng thể cho một dự án web, cách thức phân tách các thành phần của một ứng

Một số công nghệ áp dụng kiến trúc Model - View - Controller

dụng thành các thành phần M odel, View, C ontroller cũng như cách thức phối hợp các thành phần đó lại để tạo thành m ột ứng dụng w eb hoàn chinh

C hương này cùng trình bày về một số công nghệ áp dụng kiến trúc M VC như: Công nghệ J2EE, Struts Fram ew ork , PHP

CHƯƠNG I TỎNG QUAN VÉ MVC 1.1 Lịch s ử phát triển cùa MVC

Tháng 8 năm 1973, tại thành phố Oslo của Na Uy, Tiến sỹ Trygve Reenskaug lúc đó đang làm việc cho Viện Nghiên cứu Công nghiệp Trung ương (Central Institute for Industrial R esearch) đã viết bài báo “Quản lý điều hành trong xưởng đóng tàu” (Administrative Control in the Shipyard) và đã công bố lần đầu tiên tại hội thào quốc tế về các ứng dụng máy tính trong ngành đóng tàu vào mùa thu năm đó Trong bài báo của mình, Reenskaug đã phân tích xưởng đóng tàu hiện đại như một hệ thống thông tin và đưa ra nhiều kliía cạnh kỳ thuật cũng như các khía cạnh xã hội phức tạp vốn có của một xường đóng tàu Với mục tiêu làm giảm độ phức tạp cho một ứng dụng máy tính, ông đă đề xuất hàng loạt các công nghệ nên được sử dụng trong việc mô

tá m ột hệ thống Ý tưởng trung tâm trong chiến lược của ông là “phân rã một

hệ thống lớn hay một hệ thống phức tạp thành các m ô đun thành phần”

Tiếp đến, Reenskaug mô tả các yêu cầu tổng quát mà một framework cần có để có thể xây dựng các hệ thống mới trên nền một hệ thống đã có, phù hợp với cái đã có và hệ thống mới có đủ tính mềm dẻo để có thể thích ứng với các thay đồi trong tồ chức, ô n g đưa ra các tính chất m à một framework cần

có là:

1 Có thể can thiệp thủ công vào hệ thống m ột cách dễ dàng

2 Các nhóm trong xưởng tàu phải có trách nhiệm, quyền hạn và năng lực phù hợp Hệ thống xử lý dữ liệu tổng hợp phải được chia thành các hệ thống con gẳn với từng vùng trách nhiệm Các hệ thống con sẽ được điều khiển và phát triển dựa trên từng nhóm cụ thể

3 M ột hệ thống con phải có trách nhiệm rõ ràng để những người trong

Một số công nghệ áp dụng kiến trúc Model — View — Controller

hệ thống đó có thể hiểu về các hoạt động của nó một cách đầy đủ.

4 Tất cả các hệ thống con phải có tính mở để có thề gắn kết với các

hệ thống con khác cùng nhóm hoặc khác nhóm trách nhiệm

5 Hệ thống tổng thể phải có khả năng phát triển tiếp; có thể thêm vào các hệ thống con mới hay thay đổi các hệ thống con cũ mà không cần xây dựng lại toàn bộ hệ thống Nó có thể nhúng một hệ thống lạ vào mà không cần thiết lập lại hệ thống Việc chuyển đổi thế hệ của một hệ thống là đơn giàn

M ặc dù, nền tàng về một framework cùa Reenskaug rất vững chẳc, nhưng lại thiếu m ột ngôn ngữ lập trình hướng đối tượng để có thể trờ thành cái được gọi là M V C

M ột vài năm sau đó, tại Califonia, Reenskaug đã được tiếp cận với chiếc máy tính A LTO , đây là “chiếc máy vi tính đầu tiên trên thế giới có khả năng điều khiển thông qua các giao diện” N hờ đó, nó đã giúp ông và các đồng nghiệp của mình phát hiện thấy “M VC là một giải pháp cho việc điều khiển các tập dữ liệu lớn và phức tạp” - khi đó là vào năm 1978, tại Xerox Palo Alto R esearch C enter (PARC)

M ô tả m ột fram ew ork để làm công việc này là một vấn đề không dễ dàng Công việc khó nhất là tìm tên cho các thành phần kiến trúc khác nhau của hệ thống, R eenskaug viết “M odel - View - Editor là tập thứ nhất” Trong bài báo “ Thing - M odel - View - Editor” ông đã định nghĩa các khái niệm sau:

Thing: “N hững cái mà người sử dụng quan tâm ” (khái niệm về thế giới thực)

M odel: “ M ột trình diễn tích cực cùa việc trừu tượng hóa trong một

Một sổ công nghệ áp dụng kiến trúc Model - Vietv — Controller

định dạng dừ liệu trong một hệ thống máy tính) (Trừu tượng hóa của Thing).

View: “ M ột hoặc nhiều trình diễn hình tượng của M odel”

Editor: “ Một giao diện giữa một người dùng và một hoặc nhiều View” (Sau này gọi là “Controller” và “Tool”)

Từ các thiết kế ban đầu này, kiến trúc M V C được ra đời và xuất hiện lần đầu tiên trong ngôn ngữ lập trình SmallTalk-80 Trong đó, Model là sự trừu tượng hóa của thế giới thực, View là trình diễn trực quan và Controller là các nút bấm, các thanh trượt cho phép người dùng tương tác với hệ thống Các thành phần trong M VC được kết nối với nhau và mồi thành phần có thề liên kết với hai thành phần còn lại, vi thế không còn phức tạp trong việc phân tầng và trừu tượng hóa Khi đó, Reenskaug thích sử dụng khái niệm Tool hơn

là Controller

Không lâu sau đó, Tiến sỹ Reenkaug rời phòng thí nghiệm PARC và cộng tác làm việc với Jim A lthoff và Dan Ingalls Vì tính hiệu quả của M VC trong ngôn ngừ lập trìng SmallTalK-80 m à M V C được tiếp tục phát triển đến ngày nay, nó là một m ẫu thiết kế hiệu quả và phù hợp cho thiết kế các thành phần giao diện người dùng

Tiến sỹ Reenskaug đã không ngừng nghiên cứu về M VC và trong những năm gần đây ông bắt đầu xuất bản tài liệu về ngôn ngừ mẫu thiết kế MVC Tuy nhiên, ông chưa bao giờ nói đến việc mẫu thiết kế M VC có thể được sử dụng để giãi quyết bài toán cho các ứng dụng trên các kiến trúc nhiều tầng [4]

Sau này, M V C được áp dụng nhiều trong các GUI Framework như: NeX TSTEP, O PEN STEP, C ocoa, M icrosoft Foundtion C lass (M FC) hay trong thư viện đồ hoạ của Java Swing Gần đây, bat đầu từ 1998, M V C đã được áp dụng cho các ứng dụng web, giúp những nhà phát triền phần mềm có

Một số công nghệ áp dụng kiến trúc Model - View - Controller

thể xây dựng được các ứng dụng web có độ phức tạp cao, qui mô lớn m à với cách tiếp cận truyền thống khó có thể đáp ứng được Các W eb Fram ework nồi tiếng hiện nay là: JavaServer Face (JSF), Apache Struts, W ebw ork2, FuseBox, M ach-II, M aypole, Catalyst, ZNF, A pache Cocoon, Ruby on Rails

và nhiều các ứng dụng khác như: W ebObject, Tapestry

Nghiên cứu về M V C là một công việc khó Do vậy, để có thể hiểu rõ

về M VC được dễ dàng hơn, trước hết chúng ta cần có kiến thức vể thiết kế theo mô hình mẫu (design pattern)

1.2 Thiết kế theo mô hình mẫu (design pattern)

1 2 1 Đ ị n h n g h ĩ a

Trong kỹ nghệ phần mềm, mẫu thiết kế là một giải pháp chung cho inột vấn đề thường gặp trong thiết kế v ấ n đề này thường được “lặp đi lặp lại” trong nhiều dự án Nói cách khác, mẫu thiết kế được xem như là một

“ khuôn mẫu” có sằn áp dụng được với nhiều tình huống khác nhau để giải quyết một vấn đề trong một hoàn cảnh cụ thể [7]

Thiết kế theo mô hình mẫu là quá trình áp dụng các mẫu có sẵn vào một ứng dụng cụ thể nào đó v ấ n đề then chốt của thiết kế theo mô hình mẫu

là hiểu rõ về từng m ẫu bao gồm các ưu điểm, nhược điềm và khả năng thành công cũng như cách thức áp dụng các mầu đó vào từng hoàn cảnh cụ thể

1 2 2 L ợ i í c h c ủ a t h i ế t k é t h e o m ô h ì n h m ẫ u

Thông thường, mọi người thường chỉ hiểu cách thức áp dụng m ột kỳ thuật thiết kế phần mềm cho một vấn đề cụ thể nào đó Do vậy, chúng khó có thể được áp dụng cho các vấn đề ờ một phạm vi lớn hơn Thiết kế theo mô hình m ầu cung cấp một giải pháp chung để giải quyết nhiều vấn đề khác nhau.[7][l] Thiết kế theo mô hình mẫu có rất nhiều các lợi ích có thể kể ra sau đây:

Một số công nghệ áp dụng kiến trúc Model - View - Controller

- Giúp các nhà phát triển nhanh chóng tìm ra các giải pháp.

- Giúp những nhà nghiên cứu này sinh nhiều ý tưởng mới và độc đáo

- Giúp các nhà thiết kế trao đổi với nhau một cách dễ dàng

- Có thể đưa ra các lời giải cho một vấn đề cụ thề

- Tận dụng được các kinh nghiệm của những người đi trước

- Biết được hiệu quả của mồi giải pháp trong từng hoàn cành cụ thể

- Có thề tìm đ ư ợ c lời giái tốt nhất cho m ột vấn đề

Tóm lại: "thiết kế theo mô hình mẫu giúp người thiết kế học được sự thành công từ người khác và tránh đi các thất bại cho bản thân"

1 2 3 P h â n l o ạ i c á c m ẫ u t h i ế t k é

Ngày nay, có rất nhiều các mẫu thiết kế khác nhau được sử dụng vào quá trình thiết kế phần mềm Tuy nhiên, các mẫu thiết kế này đều được xây dựng dựa trên 23 m ẫu thiết kế cơ bàn của G o f (Gang o f Four - có nghĩa là

“nhóm 4 người bạn” - quốc tịch Trung Quốc) G o f chia các mẫu thành 3 nhóm chính sau đây:

tượng là: Factory Pattern, Abstract Factory, Singleton Pattern, Prototype Pattern, Builder Pattern

- N h ó m c ấ u t r ú c : bao gồm các mẫu thiết kế về cách thức liên kết các đối tượng thành các cấu trúc lớn hơn: A dapter Pattern, Brigde Pattern, Com posite Pattern, D ecorator Pattern, Façade Pattern, Flyweight Pattern, Proxy Pattern

- N h ó m tư ơ n g tác đ ộ n g bao gồm các mẫu thiết kế về cách thức để các đối tượng có thề liên lạc được VỚI nhau: Chain o f Resp Pattern, Command

Một sổ công nghệ áp dụng kiến trúc Model - Vieyv - Controller

Pattern, Interpreter Pattern, Iterator Pattern, M ediator Pattern, Memento Pattern, O bserver Pattern, State Pattern, Strategy Pattern, Template M ethod, Visitor Pattern.

Ngoài các mẫu thiết kế cơ bản cùa Gof, rất nhiều các mẫu thiết kế tổng hợp khác đã được xây dựng lên và cũng đã rất thành công

1.3 Kiến trúc MVC

M VC là một kiến trúc phần mềm chia M odel (mô hình dừ liệu), View (phần hiển thị hay giao diện người dùng), C ontroller (phần điều khiển hay điều khiển chức năng) của một thành phần hay một ứng dụng thành ba phần tách biệt, vì thế khi thay đồi trên một trong ba thành phần đó sẽ ảnh hưởng ít nhất đến các thành phần còn lại

M VC thường được hiểu là một mẫu thiết kế phần mềm Tuy nhiên, MVC mang nhiều ý nghĩa về kiến trúc phần mềm hơn một mầu thiết kế thông thường Vi thế, M V C thường được gọi là một kiến trúc phần mềm (Bruschmann đưa ra năm 1996), mầu thiết kế phần mềm tổng hợp hay mẫu của mẫu thiết kế M V C được tổng họp từ nhiều các mẫu thiết kế nhỏ hơn: View áp dụng mẫu Com posite Pattern, giao tiếp giữa View và M odel sừ dụng mẫu O bserver Pattern; Controller sử dụng mẫu Strategy Pattern hay Command Pattern; và một số mẫu khác như: M ediator Pattern, Decorator Pattern, A daptor Pattern, Factory Pattern [7]

1 3 1 M o d e l ( M ô h ì n h d ữ l i ệ u )

M odel nắm giữ các dừ liệu, thực hiện các chức năng liên quan đến việc truy cập dừ liệu hay thay đồi các dữ liệu của chương trình Model thường được chia thành hai hệ thống con đó là: các trạng thái nội tại của hệ thống và các hành động làm thay đồi các trạng thái cùa hệ thống, v ề mặt ngữ pháp học,

có thể hiểu các trạng thái nội tại của hệ thống như các danh từ và các hành

M ột số công nghệ áp (lụng kiến trúc M odel - View — Controller

động làm thay đổi các trạng thái của hệ thống là các động từ.

Mỗi một ứng dụng (hoặc thành phần) có một M odel khác nhau Ví dụ, Model của m ột thanh cuộn (scrollbar) có thể chứa các thông tin hiện tại của

nó, giá trị lớn nhất, nhỏ nhất hay độ rộng của thumb M odel có thể chịu trách nhiệm giao tiếp một cách gián tiếp với View và Controller Gián tiếp có nghĩa

là M odel không hề biết các View và Controller của nó - nó không duy trì các tham chiếu đến chúng Thay vào đó, M odel gửi đi các thông báo đến View và Controller khi có sự thay đổi trạng thái của hệ thống

1 3 2 V i e w ( H i ể n t h ị h a y g i a o d i ệ n n g ư ờ i d ù n g )

View liên quan đến việc bạn nhìn thấy các thành phần trên màn hình như thế nào Một ví dụ dễ thấy về sự khác nhau giữa các hiển thị, hãy nhìn vào một ứng dụng cừa sồ (window) trên hai hệ điều hành khác nhau Hầu hết các cửa sồ có một thanh tiêu đề nằm ở phía trên Tuy nhiên, thanh tiêu đề có thể có một nút close (dấu X) phía bên trái trong hệ điều hành MAC, hoặc có một nút close (dấu X ) phía bên phải trong hệ điều hành W indows

View xác định việc hiển thị trực quan dữ liệu của Model View chịu trách nhiệm cập nhật những thay đồi của nó trên màn hình View có thể nhận những thông báo gián tiếp từ Model hoặc các thông điệp từ Controller

1 3 3 C o n t r o l l e r ( Đ i ê u k h i ể n h a y Q u ả n l ý c h ứ c n ă n g )

C ontroler là hành vi của ứng dụng Nó tập trung việc nhận các yêu cầu cùa người dùng, chuyển các yêu cầu của người dùng đến chức năng xử lý yêu cầu của M odel và chuyền kết quả trả về cho View hiển thị

Controller có thể nhận thông điệp từ View và những thông điệp gián tiếp từ M odel

Hình dưới chỉ ra M odel, V iew , C o n tro ller làm việc với nhau như thế

M ột số công nghệ áp (lụng kiến trúc M odel - View - Controller

nào để tạo ra một thanh cuộn (scrollbar) M odel nắm giữ thông tin về giá trị nhò nhất (min), lớn nhất (max) View xác định chính xác vẽ scrollbar như thế nào và vẽ ở vị trí nào Cuối cùng C ontroller chịu trách nhiệm xử lý các sự kiện chuột Kết quả scrollbar mang đầy đủ chức năng của MVC.

và Controller có thể truy cập vào các chức năng của M odel View lấy dừ liệu

từ Model và chịu trách nhiệm hiền thị chúng Nó tự động cập nhật việc hiển thị khi có sự thay đổi trong M odel Đ ồng thời, View cũng làm nhiệm vụ là chuyển các yêu cầu của người dùng đến Controller Controller lựa chọn chức năng xử lý yêu cầu của người dùng và lựa chọn thành phần hiển thị tiếp theo Trong các ứng dụng đồ họa, các yêu cầu có thể là các sự kiện bàn phím, chuột hoặc từ việc lựa chọn các menu Trong các ứng dụng web, chúng còn là các yêu cầu HTTP PO ST , G E T Controller lựa chọn thành phần hiển thị tiếp theo dựa vào tương tác của người dùng hoặc dựa vào kết quả xử lý trả về từ Model

Một số công nghệ áp dụng kiến trúc Model - Vieyv - Controller

'ế mm ip Evw»s

Hình 1.3.4 Sự tương tác giừa các thành phần của M VC

M ột ứng dụng thông thường sử dụng một bộ điều khiển cho một nhóm các chức năng liên quan nào đó M ột số ứng dụng khác có thể sử dụng nhiều

bộ điều khiển độc lập cho mỗi loại người dùng vì có thể có nhiều View khác nhau úng với mỗi loại người dùng khác nhau

1 3 5 M ộ t s ó đ ặ c đ i ể m c ơ b ả n c ù a M V C

Một điều dễ nhận ra là các View thường xuyên được thay đổi theo thời gian cho phù hợp với từng loại người dùng, trong khi M odel thì lại rất ít khi thay đổi D o đó, việc phân tách giữa M odel và View giữ cho Model không

bị thay đồi khi viết lại giao diện Hơn nữa, hoạt động cùa mỗi chức năng trong

hệ thống thường là phức tạp và khó hiểu cho tới khâu thực thi cuối cùng Vì thế, trong một số dự án, các View có thể được thiết kế ngay trong các khâu đầu tiên của quá trình thiết kế còn M odel sẽ được hoàn thiện dần trong suốt quá trình phát triển

M ặc dù M odel và C ontroller là hai khái niệm riêng rẽ trong kiến trúc

M VC nhưng thực tế chúng lại có mối quan hệ rất chặt chẽ Mồi thay đổi liên

Một số công nghệ áp dụng kiến trúc Model - View - Controller

quan đến Model sẽ tạo ra một thay đổi tương ứng đến Controller.

Kiến trúc M V C cho phép m ột ứng dựng có thể được xây dựng trên nhiều ngôn ngữ lập trình khác nhau Do M odel và Controller là độc lập với View nên View chỉ cần thông báo cho C ontroller các sự kiện người dùng và cập nhật nhũng thay đổi của M odel

1.4 Một số các mẫu thiết kế trong MVC

M VC là một mầu thiết kế tổng hợp được cấu thành từ nhiều mẫu thiết

kế cơ bản: View áp dụng mẫu C om positePattem kết hợp với D ecoratorPattem

để xây dựng thành phần hiển thị, giao tiếp giữa View và M odel sừ dụng mẫu

O bserverPattem ; C ontroller sử dụng m ẫu StrategyPattem đề phân phối các yêu cầu của người dùng cho các chức năng của Model; M odel sử dụng

M ediatorPattem để quản lý các đối tượng trong hệ thống; View sử dụng

A dapterPattem để chuyển giao diện của M odel sang một giao diện chuẩn mà View có thể hiểu được; Ngoài ra M V C còn sử dụng rất nhiều các mẫu thiết kế khác để hỗ trợ quá trình xây dựng cũng như liên kết các thành phần M odel, View, C ontroller

1 4 1 C o m p o s i t e P a t t e r n

Trong một hệ thống, mỗi thành phần có thể là một đối tượng độc lập hoặc một tập các đối tượng Com posite Pattern thường được sử dụng để xây dựng các cấu trúc dữ liệu hình cây Tóm tại, C om posite Pattern là một tập hợp các đối tượng m à bất kỳ một đối tượng con nào của nó lại có thể là một

C om positePattem hoặc là một đối tượng cơ sở Với khái niệm cây, một số đối tượng được gọi là các "điểm nút" (node) và một số khác được gọi là "lá" (leaf)

Vấn đề ở đây là xác định được một giao diện duy nhất để có thể dề dàng truy cập vào các đối tượng trong cây đồng thời đảm bảo việc phân biệt

Một số công nghệ áp dụng kiến trúc Model - View - Controller

được các điểm nút và lá Điểm nút là đối tượng chứa các đối tượng con (các nút khác hoặc lá) và các con có thể được xóa bỏ hoặc thêm vào nút hiện thời

Lá là các đối tượng không chứa các đối tượng con

M ột số tác giả đưa ra giải pháp phân tách giữa nút và lá bằng cách xây dựng các phương thức khác nhau cho các đối tượng nút và lá Trong đó, các đối tượng lá có thể có các phương thức như:

public String getNameO; //Lây tên đối tượng

public String getValueO; //Lấy giá trị đối tượng

và các đối tượng nút có thêm các phương thức như:

public Enumeration elemer»ts(); //Lấy danh sách các con cúa nút

public Node getChild(String nodeName); //Lấy một con nào đó

public void add(Object obj); //Bố sung một con

public void remove(Object obj); //Loại bỏ một con

Tuy nhiên, m ột cách tiếp cận khác được khuyên dùng là coi tất cả các đối tượng trong cây đều là các Com posite Pattern Khi đó sẽ có một giao diện duy nhất cho tất cà các đối tượng Bằng việc sử dụng phương thức elements(),

có thể dễ dàng xác định được đổi tượng nào là nút (nếu trà về một danh sách các đối tượng con) và đối tượng nào là lá (trả về một danh sách rỗng)

Một ứng dụng thông thường đòi hỏi các trang màn hình hiển thị phải

có một bố cục thống nhất được gọi là template Tem plate là một thành phần hiển thị được tồng hợp từ nhiều thành phần hiển thị nhỏ hơn theo một cách bố trí nhất định M ồi thành phần hiển thị nhỏ hơn như phần tiêu đề trang, các menu, phần nội dung hay phần cuối của một trang là các thành phần độc lập Chúng có thể là m ột thành phần đơn lẻ hoặc bao gồm các thành phần hiền thị nhổ hơn

Việc sử dụng các tem plate trong thiết kế ứng dụng làm cho việc bào trì trở nên dề dàng hơn Việc thay đổi bố cục của tem plate sẽ làm thay đổi bố cục của tất cả các trang màn hình áp dụng tem plate đó Hơn thế, các thành

Một số công nghệ áp dụng kiến trúc Model - Vieìv — Controller

phần hiển thị được chia nhỏ thành các thành phần hiền thị nhỏ hơn, mồi thành phần hiển thị nhò hơn này được gọi đến bàng cách tham chiếu Vì thế, việc thay đổi m ột thành phần hiển thị đồng nghĩa với việc thay đổi tên tham chiếu (tên file nguồn, hay đường dẫn) của nó trong thành phần hiển thị lớn hơn [1]

Trong kiến trúc M V C , thành phần V iew được xây dựng trên mẫu thiết

kế Composite Pattern kết hợp với mẫu D ecorator Pattern

1.4 2 O b s e r v e r P a t t e r n

Trong the giới phức tạp của các ứng dụng w indow , chúng ta thường mong muốn tại m ột thời điềm xác định có thể có nhiều kiểu hiển thị khác nhau cho cùng một nội dung dữ liệu và tất cả các thể hiện đó đều có thề phản ánh được những thay đổi bên trong nội dung cùa dừ liệu đó Ví dụ, khi mô tả các thay đổi về giá cả hàng hóa bán ra bầng cả hình ảnh lẫn bảng báo cáo Mỗi lần giá cả thay đổi, chúng ta mong muốn cả hai trình diễn đều cùng tự động thể hiện thay sự thay đổi đó

cmnvrẬ ếmmtằ \

C o n t r o l l e r

Hình 1.4.2 C ác cách hiển thị khác nhau của cùng một dữ liệu

O bserverPattem già sử đối tượng chứa dữ liệu là độc lập với đối tượng hiển thị và đối tượng hiển thị sẽ theo dối các thay đồi của đối tượng chứa dừ liệu

Một số công nghệ áp dụng kiến trúc Model - View — Controller

Gọi đối tượng mang dữ liệu là các Subject (M odel) và đối tượng hiền thị là các O bserver (View ) Mỗi một O bserver đăng ký theo dõi một Subject bầng cách gọi một hàm công khai (public) của Subject Khi đó, mỗi Observer cần một giao diện để Subject gọi khi dữ liệu thay đổi

abstract interface Observer{

//Gửi thông báo cho các Observer biết đã có sự thay đối

public void sendNotify(String s);

>

abstract interface Subject{

//Đăng ký theo dõi với Subject

public void registerInterest(Observer obj);

}

Để có thể theo dõi đối tượng Subject, mỗi O bserver cần đăng ký với Subject bằng cách gọi hàm registerlnterest của Subject Khi có các sự kiện làm thay đổi dữ liệu, Subject sẽ gọi phương thức sendNotify của O bserver và

O bserver sẽ tự động thay đồi các hiền thị của mình

Trong kiến trúc M V C, việc giao tiếp giữa M odel và View sử dụng mẫu thiết kế O bserver Pattem M odel đóng vai trò là đối tượng mang dữ liệu (Subject) và V iew đóng vai trò là đối tượng hiền thị (Observer) Model chịu trách nhiệm thông báo cho View biết khi có sự thay đổi và cung cấp khả năng cho phép View có thể lấy các thông tin về trạng thái cùa hệ thống View lấy

dừ liệu từ M odel và chịu trách nhiệm hiển thị các nội dung đó Nó tự cập nhật việc hiển thị khi có sự thay đổi trong mô hình [1 ] [2] [3] [4]

1.4 3 S t r a t e g y P a t t e r n

Strategy Pattern bao gồm một tập các thuật toán được bao gói trong một lớp điều khiển được gọi là Context Chương trình client có thề lựa chọn một trong những thuật toán đó, đôi khi Context tự lựa chọn thuật toán tốt nhất cho client M ục đích của Strategy Pattern là chuyển đổi các thuật toán một cách dễ dàng m à không cần sử dụng các câu lệnh điều khiển Tại một thời

Một số công nghệ áp dụng kiến trúc Model - VieìV - Controller

điểm chỉ có một thuật toán được lựa chọn C ác thuật toán trong Strategy Pattern nhiều hay ít đều cùng giải quyết một vấn đề.

Có thề có nhiều thuật toán để xử lý m ột chức năng cùa một chương trình Chương trình có thể lựa chọn m ột trong số các thuật toán này dựa vào tính hiệu quả của chúng hoặc do người dùng lựa chọn C ác thuật toán này có thể được thêm vào, bớt đi hay thay đổi tại bất kỳ thời điểm nào Strategy Pattern cho phép lựa chọn động một trong các thuật toán đó

Một sổ trường hợp có thể có các lựa chọn làm cùng một việc bầng nhiều cách thức khác nhau như:

- Lưu file trong các định dạng khác nhau

- N én file sử dụng các thuật toán khác nhau

- Thu video bàng các định dạng khác nhau

- Sử dụng các chiến lược ngắt dòng khác nhau đế hiển thị văn bản.

- Biểu diễn cùng một dữ liệu bằng nhiều định dạng khác nhau như: biểu đồ đường thẳng, biểu đ ồ hình tròn

Trong mồi trường hợp, chương trình sẽ yêu cầu C ontext lựa chọn một trong các thuật toán để thực hiện

Ỷ tường đằng sau Strategy Pattern là bao gói nhiều chiến lược khác nhau và cung cấp m ột giao diện đơn giàn cho phép chọn lựa một trong những chiến lược đó C ác chiến lược có cùng một giao diện chương trình, tuy nhiên mỗi thành phần của nó không cần có cùng cấu trúc

Già sừ cần xây dựng một chương trình sắp xếp các số tự nhiên bằng các thuật toán khác nhau như: Q uicksort, Shell Sort, M ergeSort, các thuật toán này có thể được lựa chọn một cách ngầu nhiên Khi đó, sử dụng Strategy Pattern bằng cách xây dựng các đối tượng sau đây:

Một số công nghệ áp dụng kiến trúc Model - View - Controller

- SortStrategy (Strategy): Mô tà một giao diện chung cho tất cả các thuật toán Đối tượng SortList (Context) sê sử dụng giao diện này để gọi một thuật toán xác định được định nghĩa trong các đối tượng thực thi.

- Q uickSort, ShellSort, M ergeSort (C oncrete Strategy): Là các đối tượng cụ thể thực thi giao diện SortStrategy

- SortList (Context): Tham chiếu đến SortStrategy và gọi một trong các đối tượng cụ thể thực thi các thuật toán Q uickSort, ShellSort, MergeSort SortList chứa một thể hiện biến của SortStrategy SortList cũng có thể định nghĩa một giao diện cho phép SortStrategy có thể truy cập vào dừ liệu cùa mình

Khi thực thi chương trình, SortList sẽ khởi tạo biến thể hiện của SortStrategy trong nó bằng một trong các đối tượng cụ thể như QuickSort, ShellSort, M ergeShort Và sau đó gọi các phương thức thực thi của các đối tượng cụ thể đó N hư vậy, một trong các thuật toán (QuickSort, ShellSort,

M ergeSort) có thể được thực hiện trong lúc chương trình đang chạy, tùy thuộc vào lựa chọn cùa người dùng hay việc tính toán hiệu quả cùa hệ thống [1]

Có hai cách đề làm việc này là kế thừa và liên kết Cách thứ nhất, tạo

ra một đối tượng mới kế thừa đối tượng cần chuyển giao diện, sau đó thêm các phương thức cần thiết để có thể chuyển nó sang giao diện mong muốn Cách thứ hai, tạo ra m ột đối tượng mới chứa một biến thể hiện cùa đối tượng

Một số công nghệ áp dụng kiến trúc Model - View - Controlỉer

cần chuyển giao diện, sau đó xây dựng các phương thức đề chuyển các lời gọi đến đối tượng cũ thông qua giao diện của đối tượng mới.

A dapter Pattern tập trung vào giải quyết sự tương thích giữa hai giao diện đang tồn tại, giàm công sức viết lại m ã lệnh xuống một mức tối thiểu có thể được A dapter Pattern hướng tới việc tái sử dụng các giao diện có sẵn và chỉ thực sự cần thiết khi mọi thứ đã được xây dựng từ trước A dapter Pattern được ứng dụng trong các trường hợp sau:

- Cần tích họp một vài mô đun vào chương trình

- Không thể sát nhập trực tiếp mô đun vào chương trình

- Mô đun đang tồn tại không có giao diện như mong muốn: cần nhiều các phương thức hơn cho mô đun đó hoặc một số phương thức cần phải viết lại (chồng phương thức) [1] [2] [3] [4]

Trong kiến trúc M VC, View thường sừ dụng Adapter Pattern để chuyển Model sang m ột giao diện chuần mà View có thể sử dụng được

1 4.5 C o m m a n d P a t t e r n

Khi xây dựng một ứng dụng cần cung cấp một danh sách các menu lựa chọn các chức năng như m ở file, thoát hay thay đổi màu nền M ỗi khi người dùng lựa chọn một chức năng, chương trình sẽ gọi một hàm xử lý tương ứng bằng m ột cấu trúc điều khiển như sau:

public void action Performed(ActionEvent e) {

Object obj = e.getSourceO;

if(obj == mnuOpen) fi!eOpen();//mở file

if(obj == mnuExit) exitClicked();//thoát chương trình

if (obj == btnRed) redClicked();//chuyển màn màu đỏ

nên cồng kềnh Hơn nữa, các ngôn ngữ lập trình hướng đối tượng thường cố gang tránh sử dụng một dãy các câu lệnh điều khiển để quyết định đổi tượng nào được lựa chọn.

Command Pattern tập trung vào giải quyết vấn đề đó bằng cách chẳn chắn rằng các đối tượng sẽ luôn nhận trực tiếp các lệnh Command Pattern thực hiện việc bao gói một chức năng cùa ứng dụng trong một đối tượng Đối tượng này thực thi m ột giao diện cho phép giao tiếp với các chương trình client, ứ n g dụng sẽ thực hiện các chức năng thông qua lời gọi hàm trên giao diện đó Các client không biết gì về hoạt động bên trong đối tượng và các thay đổi bên trong đối tượng cũng không ảnh hưởng tới các chương trình phía client

Để chắc chắn mỗi đối tượng sẽ nhận đúng lệnh ứng dụng yêu cầu, chúng ta sử dụng m ột đối tượng tên là Com mand, đổi tượng này luôn chứa phương thức Execute như sau:

public interface Command{

public void ExecuteO;

>

Bây giờ, phương thức actionPerform ed trở thành:

public void actionPerformed(ActionEvent e) {

Command cmd = (Command) e.getSourceO;

cmd.ExecuteO;

>

Sau đó, xây dựng phương thức Execute cho mỗi đối tượng xử lý các chức năng mong đợi Khi đó, chỉ cần quan tâm đến chức năng của đối tượng chửa chức năng đó m à bỏ qua thành phần chương trình thực hiện việc lựa chọn quyết định

M ột mục đích quan trọng nữa của Com m and Pattern là phân tách chương trình khỏi giao diện sử dụng Nói cách khác, các đối tượng chương

Một sổ công nghệ áp dụng kiến trúc Model - View — Controller

trình này sẽ hoàn toàn không biết gì về các đối tượng khác Giao diện người dùng nhận lệnh và yêu cầu đối tượng Command xử lý Giao diện người dùng không biết cũng như không cần biết chức năng nào trong Command sẽ được thực thi.

Command Pattern cũng được sử dụng để báo cho chương trình biết thời điềm thích hợp để thực hiện lệnh mà không phải là ngay lập tức Trong trường hợp này, có thể đưa các lệnh vào trong hàng đợi đề chương trình sê thực hiện lần lượt Cuối cùng, đối tượng Com mand có thể nhớ các thao tác đã thực hiện và có thể thực hiện hủy bỏ kết quà m ột thao tác đã được thực hiện (undo) [1] [2] [3] [4]

Trong kiến trúc M VC, Controller Iihận các yêu cầu từ người dùng, lựa chọn chức năng xử lỷ yêu cầu của Model và chuyền kết quả xử lý từ M odel cho khâu hiển thị tiếp theo Mỗi một chức năng xử lý yêu cầu trong M odel cần phải đăng ký xử lý một yêu cầu nhất định với Controller Khi nhận được yêu cầu từ người dùng, Controller sẽ tìm kiếm chức năng đã đăng ký xử lý yêu cầu đó Nếu thấy, nó sẽ chuyển yêu cầu cho chức năng đó xử lý và nhận

về kết quả Nếu không thấy, Controller sẽ gọi m ột chức năng mặc định để xử

lý nó hoặc hiền thị m ột thông báo lỗi

Áp dụng Com mand Pattern vào thành phần Controller cùa kiến trúc

M V C giúp cho Controller mềm dèo trong việc đăng ký các chức năng xừ lý yêu cầu, loại bỏ các câu lệnh điều khiển (if-then-else, sw itch-case) khó hiểu

và khó bảo trì, đồng thời giảm được số lượng các dòng mã lệnh đặc biệt hữu ích với các ứng dụng có qui mô lớn và phức tạp

“nhà xưởng” có nhiệm VỌI khởi tạo các đối tượng khi chạy và trà về một thể hiện trong một nhóm các đối tượng liên quan tùy thuộc giá trị các tham số nhận được Factory Pattern được sử dụng trong các trường hợp sau:

- Một đối tượng không biết trước loại đối tượng nào nó sẽ tạo ra khi thực thi

- M ột đối tượng sử dụng các đổi tượng con của nó đề mô tả đổi tượng

sẽ được tạo ra

Có nhiều dấu hiệu để nhận biết một FactoryPattem là:

- Đổi tượng cha là trừu tượng và đối tượng trà về là đối tượng cụ thể

- Đối tượng cha chứa các phương thức cơ sờ và các đối tượng con được tạo ra khi các phương thức này chưa đáp ứng được chức năng của chương trình

- Các đối số truyền cho đối tượng Factory cho biết loại đối tượng nào cần được trà về Trong trường hợp này, các đổi tượng có thể có cùng tên phương thức nhimg chúng có thể thực hiện các công việc hoàn toàn khác nhau [1] [2] [3] [4]

1 4 7 M e d i a t o r P a t t e r n

Thông thường, m ột chương trình được tạo nên từ nhiều đối tượng, các chức năng và tính toán được phân chia cho các đối tượng này s ố lượng các đối tượng độc lập dần lớn lên, việc giao tiếp giữa các đối tượng này cũng trờ nên rất phức tạp làm cho chương trình trở nên khó đọc và khó bảo trì Điều này cũng làm cho việc thay đổi chương trình trở nên khó khăn hơn khi m à bất

cứ thay đổi nào trên một đối tượng cũng kéo theo những thay đổi dây chuyền trên những đối tượng khác M ediator Pattern tập trung giải quyết vấn đề này bằng cách tạo ra m ột đối tượng trung gian điều khiển việc giao tiếp giữa các

Một số công nghệ áp dụng kiến trúc Model - View - Controller

đối tượng độc lập Khi xuất hiện thay đổi trên một đối tượng độc lập, nó sẽ gửi thông tin cho đối tượng trung gian, đối tượng trung gian sẽ chuyển những thông tin đó cho các đối tượng liên quan khác.

M ediator Pattem tạo ra một mối liên kết không trực tiếp giữa các đối tượng độc lập, đồng thời nó cũng nắm giữ các hành vi của hệ thống mà lẽ ra

sè được phân bô cho các đối tượng liên quan Do đó, M ediator Pattem giúp chúng ta có dễ dàng thay đổi hành vi của hệ thống bằng các thay đổi trên đối tượng trung gian M ediator Pattem cũng giúp chúng ta có thêm các đối tượng vào hệ thống mà không ảnh hưởng đến các thành phần khác của hệ thống Đồng thời, M ediator Pattem giải quyết được vấn đề các đối tượng độc lập cần phải biết quá nhiều thông tin về các đối tượng liên quan khác

Tuy nhiên, đối tượng trung gian có thể trở nên quá phức tạp và khó thay đổi hay bảo trì D o vậy, đối tượng trung gian chỉ nên giữ vai trò quản lý việc giao tiếp giữa các đối tượng chứ không nên can thiệp và các tác vụ của các đối tượng

Mồi đối tượng trung gian cần phải biết tất cả các phương thức của đổi tượng liên quan Do đó, khả năng tái sử dụng đối tượng trung gian này trên các dự án khác là rất khó Tuy nhiên, việc xây dựng một đối tượng trung gian lại đơn giàn hơn nhiều so với việc quàn lý các giao tiếp giữa các đối tượng độc lập [1] [ 2 ] [3] [4]

Trong kiến trúc M V C, Model có thể sử dụng M ediator Pattem để quản

lý được các đối tượng trong hệ thống

1 4 8 D e c o r a t o r P a t t e r n

Tương tự A dapter Pattem , D ecorator Pattem mở rộng một đổi tượng

cơ sở bằng hai cách là kế thừa và liên kết C ách thứ nhất, tạo ra một đối tượng mới kế thừa đối tượng ban đầu, sau đó thêm các phương thức cần thiết cho

Một số công nghệ áp dụng kiến trúc Modeỉ - View - Controỉìer

ứng dụng Cách thứ hai, tạo ra một đối tượng mới chứa một biến thể hiện của đối tượng ban đầu, sau đó xây dựng thêm các phương thức cần thiết cho ứng dụng.

Trong lập trình đồ họa, giả sử cần xây dựng m ột đối tượng cửa sổ hồ trợ khả năng cuộn m àn hình Đầu tiên, chúng ta sẽ xây dựng lớp W indow chứa các chức năng hiển thị cần thiết Tiếp đến có ba lựa chọn: M ột là, bổ sung thêm chức năng scrolling trực tiếp vào lớp W indow (Tuy nhiên, cách này có thể làm cho W indow phải lưu trữ quá nhiều thành phần mà trong nhiều trường hợp nó không sử dụng đến); Hai là, xây dựng một lớp mới tên là

W indow W ithScrolling chứa tất cả các thành phần của lớp W indow và bồ sung chức năng scrolling vào lớp này Ba là, xây dựng một lớp mới tên là ScrollingW indow bằng cách kế thừa hoặc liên kết lớp W indow (D ecorator Pattern)

Tiếp đến, chúng ta lại mong muốn tạo thêm các đường viền (border) cho tất cả các đối tượng cửa sổ Với cách thứ hai, cần phải tạo ra các lớp con khác là W indow W ithB order và ScrollingW indowW ithBorder Điều này thật tồi tệ mỗi khi một chức năng mới cần được thêm vào Tuy nhiên, với cách thứ

ba (áp dụng D ecorator Pattern) chỉ cần xây dựng một lớp con mới là

B orderedW indow D ecorator và tùy theo trạng thái của hệ thống có thể trang trí của sổ là có scrolling hay có các đường viền hay không [1] [2] [3] [4]

1.4.9 S o s á n h c á c m ẫ u t h i ế t k ế

Chain o f R esp Pattern (không trình bày ở đây), Command Pattern,

M ediator Pattern, O bserver Pattern đều tập trung giải quyết vấn đề giao tiếp giữa các đối tượng Chain o f Resp Pattern chuyển yêu cầu từ người gửi đến người nhận theo một dây chuyền Command Pattern thường đặc tà việc kết nối giữa đối tượng gửi và nhận bằng một lớp con M ediator Pattern liên kết

M ột số công nghệ áp (lụng kiến trúc M odel — View - Controller

các đối tượng gửi và nhận một cách gián tiếp O bserver Pattern định nghĩa một giao diện riêng biệt cho phép nhiều đối tượng có thể nhận thông tin từ đối tượng gửi trong lúc chương trình đang chạy []

M ediator Pattern và Observer Pattern là các mẫu thiết kế tương tranh

Sự khác nhau giữa chúng là Observer Pattern thực hiện liên kết các đối tượng bằng cách đưa ra đối tượng theo dõi O bserver và đối tượng nội dung Subject, trong khi M ediator Pattern nắm giữ các liên kết giữa các đối tượng khác Do

đó, O bserver Pattern thường được tái sử dụng còn M ediator Pattern thì không

M ediator Pattern là tương tự với Façade Pattern (không trình bày ở đây) ở chỗ nó tách các chức năng từ các đối tượng đang tồn tại M ediator Pattern tập trung các chức năng giao tiếp giữa các đối tượng, nó thường bổ sung thêm các chức năng và các đối tượng giữ m ột tham chiếu đến nó Ngược lại, Façade Pattern định nghĩa một giao diện đơn giản cho một hệ thống con,

nó không bổ sung thêm các chức năng và các hệ thống con cũng không hề biết đến nó

A dapter Pattern cung cấp một giao diện khác cho một đối tượng hiện

có Proxy Pattern (không trình bày ở đây) cung cấp một giao diện giống với giao diện của đối tượng hiện có Decorator Pattern cung cấp một giao diện mở rộng cho đối tượng hiện có

A dapter Pattern thay đổi giao diện của một đối tượng Decorator Pattern mở rộng khả năng đáp ứng của một đối tượng Kết quả, Decorator Pattern hỗ trợ đệ qui trong khi A dapter Pattern là không thể

C om posite Pattern và D ecorator Pattern có lược đồ cấu trúc tương tự, phàn ánh một thực tế là cả hai đều dựa trên việc đệ qui để sắp xếp một số lượng không hạn chế các đối tượng D ecorator Pattern có thể được xem như một C om posite Pattern suy thoái với chỉ m ột thành phần Tuy nhiên,

M ộ t số c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - V iew - C ontroller

D ecorator Pattern thêm khả năng đáp ứng cho đối tượng, khác với mục đích tập hợp các đối tượng của Composite Pattern D ecorator Pattern được thiết kế

để thêm các đáp ứng cho đối tượng mà không cần tạo thêm các lớp con Composite Pattern không tập trung vào việc trang trí mà nó tập trung vào việc trình diễn Hai mầu thiết kế này không riêng rẽ mà bổ sung cho nhau Do đó, Com positePattem và D ecoratorPattem thường được phối hợp với nhau

Com posite Pattern thường sử dụng Chain o f Resp Pattern để giúp các thành phần có thể truy cập vào các thuộc tính toàn cục thông qua đổi tượng cha Nó cũng có thể sử dụng D ecorator Pattern để thay đổi các thuộc tính của các đổi tượng cấu thành

D ecorator Pattern và Proxy Pattern khác nhau về mục đích nhưng lại giống nhau về cấu trúc Cả hai đều cung cấp khả năng truy cập gián tiếp đến một đối tượng khác và chuyển các yêu cầu đến đối tượng đó

D ecorator Pattern giúp thay đồi skin (dáng vẻ bên ngoài) cùa đối tượng, trong khi Strategy Pattern giúp thay đổi lõi bên trong của đối tượng

Dưới đây là m ột số công nghệ nền tảng được đề cập đến trong luậnvăn

1.5 G iớ i thiệu một số công nghệ nền tảng

1.5.1 HTTP, HTML và các s ự kiện

W orld W ide W eb được xây dựng trên giao thức Hypertext Transfer Protocol (HTTP) và Hypertext M arkup Language (HTML) M ột sự kiện người dùng (U ser Agent) là một tác động cùa người dùng vào hệ thống Ờ đây

là việc người dùng sử dụng trình duyệt web yêu cầu một tài liệu HTML bằng giao thức HTTP Trình duyệt sẽ định dạng và hiển thị tài liệu của người dùng HTTP được xây dựng để có thể truyền đi nhiều hơn HTM L, tuy nhiên HTM L

là không thể thiếu với các ứng dụng web. _

M ộ t s ố c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - View - C ontroller

1.5.2 Chu trình requesưresponse (hỏi/đáp) của HTTP

M ột ứng dụng web thường được xây dựng dựa trên giao thức HTTP (Hyper Text T ransfer Protocol) Ờ mức cao nhất chu trình request/response gồm 4 phần cơ bản theo thứ tự là: Đặc tà và thông dịch yêu cầu người dùng, chuyền yêu cầu cho chức năng xử lý tương ứng, lựa chọn màn hình hiển thị thích hợp, trình bày các nội dung cần hiển thị

từ

đ ẽ n

Hình 1.5.2 Chu trình hỏi/đáp (request/response) của HTTP

1.5.3 Các phiên làm việc (Session)

Lập trình w eb thường có nhu cầu theo dõi các giá trị của biến giữa các phiên làm việc và lưu giữ trạng thái giữa các lần triệu gọi trang Tuy nhiên, tính chất then chốt của HTTP là stateless (không lưu trạng thái) Do đó, trình chủ W eb serv er đưa ra đối tượng session để lưu dữ các thông tin người dùng cũng như trạng thái của hệ thống trong m ột khoảng thời gian xác định

Nhầm tránh việc các session chiếm giữ các tài nguyên lâu khi một người dùng không hoàn thành một giao dịch, các session được cấu hình bằng một tham số thời gian hết hạn của session N ếu thời gian giữa hai lần yêu cầu lớn hơn thời gian này thì session sẽ bị chết (tức là tất cả các thuộc tính của session sẽ bị xóa bỏ) C ác session này sẽ chiếm bộ nhớ trên Server và vì thế nếu số lượng người dùng lớn, chúng ta cần quan tâm đến việc giảm độ lớn của từng session

M ộ t s ố c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - View —C o n tro ller

1.5.4 XML

XM L (Extension M arkup Language) - là một ngôn ngừ định dạng mở

rộng dùng để thể hiện dữ liệu Trong quá khứ, các chương trình thường được

dùng nhiều khuôn dạng (format) khác nhau để lưu trừ dữ liệu Ví dụ như dữ

liệu được lưu trong file text phân cách nhau bằng dấu tab, hoặc trong file nhị

phân với các cấu trúc qui định các trường khác nhau, chẳng hạn file word

doc, RTF (Rich Text Form at) Do các khuôn dạng dữ liệu này khác biệt

nhau nên để đọc và nhận dạng chúng cần phải có các chương trình gốc

(những chương trình đã tạo ra file) hoặc các tác già của chương trình phải

công bố định dạng file cho các chương trình khác có thể đọc và hiểu nó

M ột vấn đề khác là dữ liệu chương trình được lưu hay biểu diễn dưới

dạng bàng Điều này đã tồn tại từ rất lâu trong các hệ cơ sở dữ liệu, ở đó cấu

trúc bảng (table) là thành phần chủ yếu để lưu trừ và truy vấn M ặc dù dữ liệu

dạng bảng tỏ ra rất hiệu quả nhưng trong một số trường hợp, chúng không thể

dùng để biểu diễn các cấu trúc dữ liệu phức tạp Chẳng hạn cấu trúc cây hay

các đối tượng lồng nhau

XM L ra đời giải quyết vấn đề này khá trọn vẹn XM L giúp thể hiện và

trình bày dừ liệu ờ mọi khuôn dạng XM L là một chuẩn cho nên được hầu hết

các chương trình chấp nhận và phân tích đúng nội dung dừ liệu Ngôn ngữ

XM L trong sáng, đơn giản, dễ đọc (vì chúng được biểu diễn dưới khuôn dạng

thuần văn bản) và nhất là dễ sử dụng với người dùng cũng như đối với

chương trình Cú pháp XM L rất giống với H TM L (và thực sự thì XML tổng

quát hơn HTM L) Tuy nhiên có một số điều mà XM L không thay thế được đó

là:

nghĩa cấu trúc dừ liệu XM L không định nghĩa cách thức hiển thị dừ liệu

M ộ t s ố c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - View - C o n tro ller

trong trình duyệt như HTML.

- XM L không định thay thế và tồng quát hóa mọi khuôn dạng dữ liệu XML phát triền thành những nhánh nhỏ qui định cách thể hiện dữ liệu riêng cho tìmg lĩnh vực

- XM L không phải là ngôn ngữ lập trình XM L cho phép mô tả dừ liệu nhưng không cho biết làm thế nào để xử lý dữ liệu Điều này tùy thuộc vào từng chương trình cụ thể sử dụng dừ liệu chứa trong file XML

1.5.5 Ngôn ngữ Java và các ứng dụng Framework

Java do Jam es Gosling, Patrick m aughton, Christ W arth, Ed và M ike Sheridan phát triển vào năm 1991 tại Sun M icrosystem , Inc Java là một ngôn ngữ lập trình hướng đối tượng được phát triển từ c++ Java có nhiều các đặc điểm nồi bật như: tỉnh đơn giản, an toàn, tương thích, hướng đối tượng, trong sáng, đa trình, trung lập, thông dịch, tốc độ cao, phân tán, linh động N gày nay, Java là m ột lựa chọn hàng đầu cho việc phát triển các ứng dụng đòi hỏi tính bảo mật cũng như không phụ thuộc vào thiết bị

Hiện nay, có rất nhiều các ứng dụng Fram ew ork được nhiều hãng phát triển Các Fram ew ork hướng đến việc tái sừ dụng các thành phần giống nhau của nhiều dự án C ác Fram ework giúp cho các nhà phát triển đỡ vất vả và nhanh chóng xây dựng được các ứng dụng m à vẫn đảm bảo tính an toàn cũng như tính bền vững của ứng dụng Chọn lựa một Fram ework tốt giúp giảm thiểu được thời gian phát triển và nâng cao chất lượng của ứng dụng Nó giúp người lập trình chú tâm vào việc phát triển các chức năng của ứng dụng thay

vì phải làm việc với từng dòng lệnh nhàm chán cùng những sai xót cá nhân cùa người lập trình

1.5.6 Java Beans

JavaB eans là một kiến trúc thành phần trong J2EE (Java 2 Platform,

M ộ t s ố c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - Vietv - C ontroller

Standard Edition) JavaB eans là các chương trình phần mềm có thề tái sử dụng để có thể phát triển và tồng hợp thành các ứng dụng phức tạp hơn Với tính chất (phản chiếu) và (đặc tả nội tại), JavaB eans cho phép các đối tượng khác có thể biết các thành phần và các phương thức bên trong của nó như: tên lóp, các biến, các phương thức và các giới hạn truy cập cùa các đối tượng khác vào các thành phần bên trong nó Không có sự hạn chế về khả năng của JavaBean N ó có thể chứa các hàm đơn giản, như là kiểm tra chính tả của một văn bàn, hoặc một hàm phức hợp, như dự đoán vốn đầu tư cổ phần

1.5.7 Java Servlet

JavaServlet thay thế các ứng dụng CGI truyền thống và là trung tâm cùa các ứng dụng w eb trên Java Java là một ngôn ngữ lập trình hướng đối tượng, do đó JavaServlet cố gắng chuyển H TTP vào trong một mẫu hướng đối tượng Điều này giúp cho người phát triển tập trung vào các chức năng chính của ừng dụng hơn là các cơ chế phức tạp của HTTP

HTTP cung cấp một cơ chế chuẩn cho việc mở rộng các dịch vụ gọi là CGI (Com mon G a te w a y Interface - Giao diện cổng giao tiếp chung) HTTP

có thể chuyển các yêu cầu của người dùng đến các chương trình CGI và các chương trình CGI trả về kết quà cho HTTP Do vậy, các yêu cầu người dùng

có thể được chuyển đến một Server quản lý các JavaServlet (trình quản lý này thường được gọi là các Java W eb Server) Server quyết định có thể xử lý yêu cầu này không bằng cách kiềm tra danh sách các Servlet của nó Nếu cỏ một Servlet đăng ký xử lý yêu cầu, Server chuyển yêu cầu cho Servlet đó và nhận kết quả trả về Cuối cùng, Server trả về kết quả cho HTTP hoặc trả về lỗi nếu không tìm thấy Servlet nào đăng ký xử lý

javax.servlet.http.H ttpServlet Nó có 4 phương thức cơ bản nhầm giúp Server

M ộ t s ố c ô n g n g h ệ ảp d ụ n g k iế n trú c M o d e l —View - C ontroller

1.5.8 Bộ lọc thông tin

Trong phiên bản JavaServlet 2.3 đưa ra một thành phần mới gọi là bộ lọc thông tin (Filter) Filter chặn các thông tin từ yêu cầu và kết quả trả về, sau đó chuyển đổi hoặc sử dụng các thông tin đó cho các mục đích như: xác thực quyền, ghi log chương trình, nén dừ liệu, định dạng dữ liệu dựa theo vùng địa lý Ngoài ra, Filter còn được sử dụng đề mã hóa dữ liệu, đánh dấu

dữ liệu, khởi động tài nguyên truy cập sự kiện, thay đổi kiểu M INE,

C aching

1.5.9 Di chuyển càc yêu cầu

Đặc tả JavaServlet mở rộng chu trình hòi/đáp của HTTP để cho phép các yêu cầu được gừi đi hay di chuyển giữa các thành phần Kiến trúc M V C

M ộ t s ố c ô n g n g h ệ áp (lụng k iế n trú c M o d e l - View - C ontroller

trong các W eb Fram ework sử dụng tính chất này để chuyển yêu cầu từ client đến các thành phần xử lý yêu cầu tương ứng M ột yêu cầu được di chuyển qua đối tượng Controller, chuyển đến đối tượng xừ lý trong M odel và cuối cùng chuyền đến View.

1.5.10 Java Server Page, Taglib, Java Server Face

Khi JavaServlet lần đầu tiên xuất hiện, nhiều nhà phát triển đã tin tường vào nó bởi năng lực mạnh mẽ, khả chuyển và khả năng mở rộng vượt

xa chuẩn CGI truyền thống

Tuy nhiên, việc viết các đoạn mã hiển thị H TM L bằng phương thức print của Servlet là một điều chán nản và trở thành một bài toán đặt ra Câu trả lời là Java Server Page (JSP) Với JSP, lập trình viên có thề dễ dàng trộn lẫn các thè HTM L với các đoạn mã Java mà vẫn có đầy đủ các tính chất của Servlet

Để bẳt đầu với một trang JSP, lập trình viên có thể bắt đầu viết một trang HTM L và sau đó thêm các tính chất động bàng cách đưa vào các mã lệnh Java hoặc dùng các thư viện thẻ có sằn cùa JSP Tuy nhiên, người phát triển có thể tự xây dựng các thẻ để sử dụng cùng với JSP, các thẻ này được

gọi là C ustom er Taglib Bên cạnh đó có rất nhiều các thư viện như vậy cũng được nhiều hãng phát triển, chúng được gọi là các thư viện thè JSP chuẩn gọi tắt là JSTL (Java Server Page Standard Tag Lib).

M ột thư viện nữa xuất hiện là Java Server Face Kỳ thuật Java Server Face (JSF) làin đơn giản hóa việc xây dựng giao diện cho các ứng dụng web

và cả ứng dụng desktop Tuy nhiên, JSF còn đang trong quá trình phát triển

và hiện tại đã có một thư viện thẻ JSF dùng cho Struts là Struts-Faces

1.5.11 Các message-resource

Các tiêu đề, thông báo, thông báo lỗi được lưu chung vào trong các

M ộ t số c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - View - C ontroller

file được gọi là các file tài nguyên thông điệp (message-resource) Các

m essage-resource giúp việc thay đổi ngôn ngừ trình bày trên các giao diện cùa ứng dụng một cách dễ dàng Ví dụ, để định nghĩa một thông báo “ Xin chào” bằng tiếng Việt Nam thì trong file m essage-resource ta thêm vào dòng

“prom t.hello = Xin chào”, đề chuyển thông báo này sang tiếng Anh thì ta thay dòng đó bang “ prom t.hello = Hello” M ặt khác, chúng ta có thê hỗ trợ đồng thời nhiều ngôn ngữ khác nhau trong một ứng dụng bằng cách tạo tương ứng một file m essage-resource cho mồi ngôn ngừ hồ trợ và tùy vào vị trí địa lý hiện tại của người sử dụng mà chương trình sẽ tự động hiển thị ngôn ngữ phù hợp hoặc người dùng tự thay đồi

M ộ t s ố c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - View - C ontroller

Trong chương này, chúng ta sẽ tìm hiểu đôi nét về việc áp dụng M V C

để xây dựng các thành phần giao diện trong ngôn ngữ lập trình SmallTalk và trong thư viện Java Swing

11.2 Áp dụng MVC trong ngôn ngữ lập trình Sm allTalk

11.2.1 Giới thiêuỉ

M ột trong những đóng góp của Xerox PA R C cho thế giới lập trình là giao diện tương tác đa cừa sổ trong ngôn ngữ lập trình SmallTalk-80 Trong các giao diện này, đầu vào chủ yếu là các sự kiện chuột, bàn phím và đầu ra chủ yếu là các văn bản và các hình ảnh tương ứng Khái niệm trung tâm phía sau giao diện người dùng của SmallTalk-80 là kiến trúc M odel - View - Controller [15]

Khi chạy một ứng dụng đồ họa, ví dụ chương trình Paint, người dùng

sẽ muốn các hình được vẽ ra sẽ nằm trong một cửa sổ của chương trình và trong một không gian nhất định nào đó thay vì các hình vẽ sẽ nằm trực tiếp trên màn hình và chồng chéo lên các thành phần giao diện khác Vậy thì sự khác nhau cơ bản của hai trường hợp này là gi ? Câu trà lời đỏ là: Có áp dụng

M ộ t s ố c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - View - C ontroller

hay không áp dụng mầu thiết kế M VC trong việc xây dựng các thành phần giao diện đồ họa C ác chương trình áp dụng M V C sẽ có hành vi thân thiện và được mong đợi hơn trong khi các ứng dụng không áp dụng M VC sẽ có các hành vi mà đa số người sử dụng không mong muốn.

Ngôn ngữ lập trình SmallTalk-80 là dự án tiên phong trong việc áp dụng M VC để xây dựng các thành phần giao diện đồ họa Trong đó, một chương trình được chia thành các thành phần M odel, View, Controller và việc liên kết giữa các thành phần đó sẽ tạo nên một ứng dụng hoàn chinh

11.2.2 Thành phần Model

Thông thường, thành phần Model nắm giữ dừ liệu của chương trình,

xử lý các yêu cầu của người dùng và trà về kết quả và thông báo cho phần hiển thị Tuy vậy, trong một số trường hợp đặc biệt, M odel có thể bị bò qua Tức là M odel không thể hiện rõ vai trò là nắm giữ các thay đổi của dữ liệu và thông báo cho View khi có các thay đổi xảy ra Các trường hợp như vậy được gọi là “khuyết M odel” (passive model)

M ột ví dụ dễ thấy là trình soạn thào W Y SIW Y G (W hat You See Is

W hat You Get - nhìn thấy nó thế nào thì nó là thế ấy) Thành phần M odel ở đây là chuỗi văn bản (String), View chịu trách nhiệm hiển thị nội dung của String lên màn hình, Controller nhận các sự kiện từ bàn phím Thông thường, khi có tác động của người dùng lên bàn phím, C ontroller sẽ nhận các sự kiện

đó và chuyển đến cho M odel xử lý chúng, tiếp đến M odel sẽ thông báo các thay đổi của hệ thống cho View biết để cập nhật những thay đổi Tuy nhiên, trong ví dụ này, mỗi khi người dùng nhập vào một chừ cái thì sẽ tương ứng với một thay đổi trong M odel và View cần phải cập nhật lại phần hiển thị Bởi vậy, View không cần chờ thông báo của M odel mà sẽ thực hiện việc cập nhật lại màn hình hiển thị ngay sau khi Controller nhận một sự kiện người dùng

M ộ t s ố c ô n g n g h ệ áp d ụ n g k iế n trú c M o d e l - View - C o n tro ller