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

ĐẠI HỌC QU ỐC GIA HÀ NỘI
T R Ư Ờ N G Đ Ạ I H Ọ C C Ô N G N G H Ệ
CÁ N X UÂ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 ã số: 1.01.10
LU Ậ N VĂN T H Ạ C SỸ
NGƯ ỜI H Ư Ở N G D ÃN K HO A H ỌC
P G S .T S VŨ Đ Ứ C T H I
H à Nội - 2005
M Ụ C L Ụ C
M ỤC L Ụ C 1
LỜI CẢ M Ơ N

.

.
4
DANH M ỤC CÁC HÌNH VẼ TRON G LUẬN V Ă N 5
MỜ ĐẰƯ 6
CHƯƠ N G I TỒ NG QU AN 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 gh ĩ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. Model (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. Composite Pattern 18
1.4.2. Observer P attern 20
1.4.3. Strategy P a ttern 21
1.4.4. Adapter Pattern 23
1.4.5. Comm and Pa ttern 24
1.4.6. Factory Pattern 26
1.4.7. Mediator P attern 27
1.4.8. Decorator Pattern 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, HTM 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 (Session) 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. Java S e rvlet 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 V C TRONG THIẾT KÉ GIA O DIỆN ĐÔ HỌA39

Một số công nghệ áp dụng kiến trúc Model - View - Controller
2
II. 1. Giới th iệ u 39
11.2. Áp dụng M VC trong ngôn ngữ lập trình S m a llT 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 Sw ing

46
11.3.1. Giới th iệ u 46
11.3.3. Java Swing 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 ing 53
CHƯ ƠNG III ÁP DỰ NG M VC TRONG CÁC ỨNG 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 ntro 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 theo
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 ode l 71
111.3. Áp dụng M VC trong công nghệ J2EE của S un
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 od el 74
111.3.4. Thành phần C o ntroller 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 od e l 81
111.4.3. Thành phần V ie w 82
111.4.4. Thành phần C on 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

3
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 on 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 FRAM EW O RK
.

.

.

.
94
IV. 1. Đặt bài to á n 94
IV.2. Sơ đồ chức năng hệ thố ng 95
IV 3. Thiết kế CSD 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
5
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ộn
Hì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 J2EE
Hỉ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 System
Hì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
6
MỞ ĐÀU
Phâ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
7
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 ổ ng q ua 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 tron g các ứ ng 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
8
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 e b IS P B illin g Sy stem b ằ ng
A p a ch e S tru ts F ram e w or k

Chương này trình bày về cách thức xây dụng một ứng dụng web cụ
thể trên Apache Struts Framework: Hệ thống ISP Billing System.
Một sổ công nghệ áp dụng kiến trúc Model — View - Controller
9
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
10
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
11
đị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
12
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 é th 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
13
- 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 th 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). Gof chia các mẫu thành 3
nhóm chính sau đây:
- Nhóm cấu thành: bao gồm các mẫu thiết kế về khởi tạo các đối
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
14
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
15
độ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 i e w (H iể n th ị 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 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 Model, 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
16
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.
yểàmsi**}
&ãiúwa~ịl&
ị
View'.
I
Acte#
íMsứimd
tmtnm
ỂÍ3ÍÌ írt t5vj:rè
:

ị
< 1 1 *
Hình 1.3.3. Các thành phần Model, View, Controller trong thanh cuộn
1.3.4. S ự t ư ơ n g tá c g iữ a c á c th à n h p h ầ n c ủ a M V C
Trong kiến trúc M VC, Model chịu trách nhiệm thông báo cho View
biết khi có sự thay đổi và cho phép View có thể lấy các thông tin về trạng thái
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, GET 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
17
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRUNG TAM THONvc» TIN THU VIEN
V “LO / 643
' í
'ế mm ip Evw»s
Hì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ù M odel 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
18
quan đến Model sẽ tạo ra một thay đổi tương ứng đến Controller.
Kiến trúc MV 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 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
MediatorPattem để 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
19
đượ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
20
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 VC, 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
21
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
22
đ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ư: Q uicksort, 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
23

- 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
24
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 đỏ
}
Với một số ít các menu thì chương trình có thể chạy rất tốt. Tuy nhiên,
khi có rất nhiều các menu và nút bấm, phương thức actionPerformed sẽ trở
Một số công nghệ áp dụng kiến trúc Model — View — Controller
25
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, ứ ng 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