Một số công nghệ áp dụng kiến trúc MODEL VIEW CONTROLLER luận văn ths công nghệ thông tin 1 01 10

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 Model - View - Controller bao gồm các kiế

C Á N XUÂN H O À N

M Ộ T S Ố C Ô N G N G H Ệ Á P D Ụ N G

K I É N T R Ủ C M O D E L - V I E W - C O N T R O L L E R

Ngành: C ông nghệ thông tin

Chuyên nghành: C ông nghệ thông tin

MỜ ĐẰƯ 6

CH Ư Ơ N G I TỒNG 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 pattern) 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 Kiến trúc M V C 14

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

1.3.2 View (Hiền thị hay giao diện người d ù n g ) 15

1.3.3 Controller (Điều khiển hay Quán lý chức năng) 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 Com posite Pattern 18

1.4.2 Observer P attern 20

1.4.3 Strategy P a tte rn 21

1.4.4 Adapter P attern 23

1.4.5 Com m and P attern 24

1.4.6 Factory Pattern 26

1.4.7 M ediator P attern 27

1.4.8 Decorator P attern 28

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

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

1.5.1 HTTP, H TM L và các sự kiện 31

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

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

1.5 4 X M L 33

1.5.5 N gôn ngừ Java và các ứng dụng Fram ew ork 34

1.5.6 JavaB eans 34

1.5.7 Jav aS erv let 35

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

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

1.5.10 Java Server Page, Taglib, Java Server Face 37

1.5.11 Các m essage-resource !37

CH Ư Ơ N G II ÁP DỰ NG M VC TRONG TH IẾT KÉ G IA O DIỆN ĐÔ HỌA39

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

II 1 Giới th iệ u 39

11.2 Áp dụng M V C trong ngôn ngữ lập trình S m allT alk 39

11.2.1 Giới th iệ u 39

11.2.2 Thành phận M odel 40

11.2.3 Thành phận V ie w 42

11.2.4 Thậnh phần C ontroller 44

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

11.3 Áp dụng M V C trong thiết kế các thành phần Java S w ing 46

11.3.1 Giới th iệ u 46

11.3.3 Java Sw ing và thiết kế M V C 48

11.3.3.1 Thành phận M odel 49

11.3.3.2 Thành phần giao diện 51

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

CH Ư ƠNG III ÁP D Ự N G M VC TRONG CÁC Ứ N G DỤNG W E B 57

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

111.2 Áp dụng M V C trong một ứng dụng web tổng q u á t 59

111.2.1 Xây dựng thành phần C o n tro ller 59

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

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

111.2.1.3 Lựa chọn trang màn hình hiển thị tiếp th eo 62

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

111.2.2 Xây dựng thành phần V iew 68

III.2.2.1 Thiế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ựng thành phần M o d el 71

111.3 Áp dụng M V C trong công nghệ J2EE của Sun 73

111.3.1 Giới thiệu về công nghệ J2 E E 73

111.3.2 Thành phần V iew 73

111.3.3 Thành phần M o d e l 74

111.3.4 Thành phần C o n tro ller 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 trong Struts F ram ew ork 80

111.4.1 Giới thiệu về Struts F ram ew ork 80

in.4.2 Thành phần M o d e l 81

111.4.3 Thành phần V iew 82

111.4.4 Thành phần C o n tro ller 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 trong ngôn ngữ lập trình P H P 85

in.5.1 Giới thiệu về P H P 85

111.5.2 Xây dựng thành phần M o d el 86

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

111.5.3 Xây dựng thành phận V iew 89

111.5.4 Xâỵ dựng thành phần C o n tro ller 91

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

CHƯƠNG IV XÂY D ự N G HỆ THỐNG ISP BILLING SYSTEM TRÊN STRUTS FRA M EW O RK 94

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

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

IV 3 Thiết kế C S D L 97

IV.4 Giao diện chương trin 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 odel 100

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

IV 5.3 Xây dựng thành phần C ontroller 103

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

KÉT L U Ậ N 105

TÀJ LIỆU THAM K H Ả O 106

PHỤ 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 Model, 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 MVC

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 Chu trình hỏi/đáp (request/response) cùa HTTP

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

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

Hình II.3.4 Giao 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 web 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 Giao diện Đăng nhập hệ thống

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

Hình IV.4.C Giao 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

Model - View - Controller (MVC) 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 MVC đà đượ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 - Controller” 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 MVC 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 Model - View - Controller bao gồm các kiến thức về lịch sử phát triền của MVC, về thiết kế theo mô hình mầu, các thành phần trong MVC, sự tương tác giữa các thành phần Model, View, Controller và một số các mẫu thiết kế cơ bản để tạo thành kiến trúc MVC

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

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

C h ư ơ n g III: Á p d ụ n g kiến trúc M V C tro n g các ứ n g d ụ n g web

Chương này trình bày về cách thức áp dụng kiến trúc MVC 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 Model, View, Controller 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 web hoàn chinh Chương này cùng trình bày về một số công nghệ áp dụng kiến trúc MVC như: Công nghệ J2EE, Struts Framework , PHP.

C h ư ơ ĩig IV : X â y d ự n g ứ n g d ụ n g w eb I S P B illin g S y ste m b ằ n g

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 Research) đã 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, ông đư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à MVC

Một vài năm sau đó, tại Califonia, Reenskaug đã được tiếp cận với chiếc máy tính ALTO, đâ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” Nhờ đó, nó đã giúp ông và các đồng nghiệp của mình phát hiện thấy “MVC 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 Research Center (PARC)

Mô tả một framework để 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, Reenskaug viết “Model - View - Editor là tập thứ nhất” Trong bài báo “Thing - Model - View - Editor” ông đã định nghĩa các khái niệm sau:

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

Model: “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 Model”

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 MVC đượ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 MVC đượ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 Althoff và Dan Ingalls Vì tính hiệu quả của MVC trong ngôn ngừ lập trìng SmallTalK-80 mà MVC đượ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ề MVC 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ế MVC 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, MVC được áp dụng nhiều trong các GUI Framework như: NeXTSTEP, OPENSTEP, Cocoa, Microsoft Foundtion Class (MFC) hay trong thư viện đồ hoạ của Java Swing Gần đây, bat đầu từ 1998, MVC đã đượ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 Web Framework nồi tiếng hiện nay là: JavaServer Face (JSF), Apache Struts, Webwork2, FuseBox, Mach-II, Maypole, Catalyst, ZNF, Apache Cocoon, Ruby on Rails

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

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

về MVC đượ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 lo ạ 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 of (Gang of Four - có nghĩa là

“nhóm 4 người bạn” - quốc tịch Trung Quốc) G of 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 tr ú 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: Adapter Pattern, Brigde Pattern, Composite Pattern, Decorator 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 of Resp Pattern, Command

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

Pattern, Interpreter Pattern, Iterator Pattern, Mediator Pattern, Memento Pattern, Observer Pattern, State Pattern, Strategy Pattern, Template Method, 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

MVC là một kiến trúc phần mềm chia Model (mô hình dừ liệu), View (phần hiển thị hay giao diện người dùng), Controller (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

MVC 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ế, MVC 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ế MVC được tổng họp từ nhiều các mẫu thiết kế nhỏ hơn: View áp dụng mẫu Composite Pattern, giao tiếp giữa View và Model sừ dụng mẫu Observer Pattern; Controller sử dụng mẫu Strategy Pattern hay Command Pattern; và một số mẫu khác như: Mediator Pattern, Decorator Pattern, Adaptor Pattern, Factory Pattern [7]

1.3.1 M o d e l (M ô h ìn h d ữ liệ u )

Model 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 Model - 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 Model 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 Model 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à Model 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 đó, Model 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 ie w (H iể n th ị h a y g ia 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 Windows

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 tr o lle r (Đ iê u k h iể n h a y Q u ả n l ý c h ứ c n ă n g )

Controler 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 Model 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ừ Model

Hình dưới chỉ ra M odel, View, Controller làm việc với nhau như thế

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

nào để tạo ra một thanh cuộn (scrollbar) Model 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 Controller 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 Model 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 Model Đồ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 POST, G ET 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»sHình 1.3.4 Sự tương tác giừa các thành phần của MVC

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 Model thì lại rất ít khi thay đổi Do đó, việc phân tách giữa Model 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 Model sẽ được hoàn thiện dần trong suốt quá trình phát triển

Mặc dù Model và Controller là hai khái niệm riêng rẽ trong kiến trúc MVC 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 VC 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 Model và Controller là độc lập với View nên View chỉ cần thông báo cho Controller các sự kiện người dùng và cập nhật nhũng thay đổi của Model

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

MVC 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 CompositePattem kết hợp với DecoratorPattem

để xây dựng thành phần hiển thị, giao tiếp giữa View và Model sừ dụng mẫu ObserverPattem; Controller 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; Model sử dụng

M ediatorPattem để quản lý các đối tượng trong hệ thống; View sử dụng AdapterPattem để chuyển giao diện của Model sang một giao diện chuẩn mà View có thể hiểu được; Ngoài ra MVC 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 Model, View, Controller

1.4.1 C o m p o s i t e P a tte 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 Composite 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, Composite 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 CompositePattem 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 Composite 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 Template 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 template 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 template sẽ làm thay đổi bố cục của tất cả các trang màn hình áp dụng template đó 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 MVC, thành phần View được xây dựng trên mẫu thiết

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

1.4.2 O b s e r v e r P a tte r n

Trong the giới phức tạp của các ứng dụng window, 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

ObserverPattem 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 (Model) và đối tượng hiền thị là các Observer (View) Mỗi một Observer đă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 Observer 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 Observer và Observer sẽ tự động thay đồi các hiền thị của mình

Trong kiến trúc MVC, việc giao tiếp giữa Model và View sử dụng mẫu thiết kế Observer Pattem Model đóng vai trò là đối tượng mang dữ liệu (Subject) và View đó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ừ Model 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 tte 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 Context 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ư: Quicksort, Shell Sort, MergeSort, 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.

- QuickSort, ShellSort, MergeSort (Concrete 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 QuickSort, 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, MergeShort Và sau đó gọi các phương thức thực thi của các đối tượng cụ thể đó Như vậy, một trong các thuật toán (QuickSort, ShellSort, MergeSort) 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]

1.4.4 A d a p t e r P a tte r n

Apdapter Pattem được sử dụng để chuyền đồi giao diện của một đối tượng này sang một giao diện khác mà Client có thể hiểu được Sử dụng Apdater Pattem trong trường hợp muốn ghép nối các đối tượng có các giao diện khác nhau bằng cách tạo ra một đối tượng mới có giao diện thích hợp, sau đó liên kết với các đối tượng liên quan

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.

Adapter 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 Adapter 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 Adapter 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 MVC, 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 tte 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à Command, đổ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 actionPerformed 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 Command 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 Command 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 MVC, 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ừ Model cho khâu hiển thị tiếp theo Mỗi một chức năng xử lý yêu cầu trong Model 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 Command Pattern vào thành phần Controller cùa kiến trúc MVC 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, switch-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 tte 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 Mediator 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.

Mediator 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 đó, Mediator 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, Mediator 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ì Do 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 MVC, Model có thể sử dụng Mediator Pattem để quản

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

1.4.8 D e c o r a to r P a tte r n

Tương tự Adapter Pattem, Decorator 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 Window 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 Window (Tuy nhiên, cách này có thể làm cho Window 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à WindowWithScrolling chứa tất cả các thành phần của lớp Window 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à ScrollingWindow bằng cách kế thừa hoặc liên kết lớp Window (Decorator 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 indowWithBorder và ScrollingWindowWithBorder Đ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 Decorator Pattern) chỉ cần xây dựng một lớp con mới là BorderedWindowDecorator 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 of Resp Pattern (không trình bày ở đây), Command Pattern, Mediator Pattern, Observer Pattern đều tập trung giải quyết vấn đề giao tiếp giữa các đối tượng Chain of 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 Mediator Pattern liên kết

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

các đối tượng gửi và nhận một cách gián tiếp Observer 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 []

Mediator 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 Observer và đối tượng nội dung Subject, trong khi Mediator Pattern nắm giữ các liên kết giữa các đối tượng khác Do

đó, Observer Pattern thường được tái sử dụng còn Mediator Pattern thì không

Mediator 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 Mediator 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ó

Adapter 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ó

Adapter 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 Adapter Pattern là không thể

Composite Pattern và Decorator 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 Decorator Pattern có thể được xem như một Composite Pattern suy thoái với chỉ một thành phần Tuy nhiên,

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

Decorator 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 Decorator 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 đó, CompositePattem và DecoratorPattem thường được phối hợp với nhau

Composite Pattern thường sử dụng Chain of 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 Decorator Pattern để thay đổi các thuộc tính của các đổi tượng cấu thành

Decorator 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 đó

Decorator 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 Giới thiệu một số công nghệ nền tảng

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

World Wide Web được xây dựng trên giao thức Hypertext Transfer Protocol (HTTP) và Hypertext Markup Language (HTML) Một sự kiện người dùng (User 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 HTML, tuy nhiên HTML

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

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

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 Transfer 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 web 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 ebserver đư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ông n g h ệ áp dụng kiến trúc M odel - View — Controller

1.5.4 XML

XML (Extension Markup 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 Format) 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

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

trình bày dừ liệu ờ mọi khuôn dạng XML 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ữ

XML 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 XML rất giống với HTML (và thực sự thì XML tổng

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

trong trình duyệt như HTML.

- XML 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

- XML không phải là ngôn ngữ lập trình XML 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 James Gosling, Patrick maughton, Christ Warth, Ed và M ike Sheridan phát triển vào năm 1991 tại Sun Microsystem, 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 Ngà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 Framework được nhiều hãng phát triển Các Framework 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 Framework 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 Framework 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

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

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

Standard Edition) JavaBeans 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), JavaBeans 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 web 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 HTTP 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 (Common G atew ay 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 Web 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.HttpServlet Nó có 4 phương thức cơ bản nhầm giúp Server

M ột số công n g h ệ ảp dụng kiến trúc M odel — View - Controller

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 MINE, Caching

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 MVC

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

trong các Web Framework 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 Model 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ị HTML 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è HTML 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 HTML 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à Customer 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ông nghệ áp dụng kiến trúc M o d el - View - Controller

file được gọi là các file tài nguyên thông điệp (message-resource) Các message-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 message-resource ta thêm vào dòng

“promt.hello = Xin chào”, đề chuyển thông báo này sang tiếng Anh thì ta thay dòng đó bang “promt.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 message-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ông nghệ áp dụng kiến trúc M odel - View - Controller

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

để 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 SmallTalk

11.2.1 Giới thiêuỉ

Một trong những đóng góp của Xerox PARC 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 Model - 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ông nghệ áp dụng kiến trúc M odel - View - Controller

hay không áp dụng mầu thiết kế MVC 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 MVC 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 MVC 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 MVC để 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 Model, 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, Model có thể bị bò qua Tức là Model 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 YSIW YG (What You See Is What You Get - nhìn thấy nó thế nào thì nó là thế ấy) Thành phần Model ở đâ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, Controller sẽ nhận các sự kiện

đó và chuyển đến cho Model xử lý chúng, tiếp đến Model 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 Model 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 Model 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ông nghệ áp dụng kiến trúc M odel - View - Controller