2. 1 Giới thiệu
Mô hình MVC: Mô hình- Khung nhìn - Điều khiển (Model-View- Controller) là một mô hình giúp ta tổ chức dự án Ajax theo nhiều cách khác nhau, giúp dễ dàng mã hoá và quản lý các dự án này. MVC đ−ợc sử dụng để chia tách các phần ch−ơng trình t−ơng tác với ng−ời dùng với phần thực hiện các công việc khác trong ứng dụng.
Mô hình MVC có 3 vai trò quan trọng trong hệ thống. Model thể hiện các vấn đề của ứng dụng. Bộ xử lý từ sẽ là mô tả một tài liệu; một ứng dụng bản đồ sẽ mô tả các điểm trên một l−ới.
View là phần ch−ơng trình mà thể hiện những thứ với ng−ời dùng: dạng đầu vào, tranh ảnh, dạng text hoặc widgets. View không cần đồ hoạ. Trong ch−ơng trình đ−ợc cài âm, dạng âm thanh cũng là View.
Yêu cầu đầu tiên đối với MVC là View và Model không trao đổi với nhau, bởi vì đấy là nơi mà Controller hoạt động. Khi ng−ời dùng ấn một phím hoặc điền vào một mẫu nào đấy, khi đó View sẽ trao đổi thông tin với bộ điều khiển. Bộ điều khiển khi đó sẽ thông tin cho Model và mô tả thời điểm những thay đổi trong View yêu cầu Model cập nhận.
Mô hình MVC th−ờng đ−ợc áp dụng cho các ứng dụng web cơ bản theo những cách đặc biệt. Khi một ứng dụng Ajax đang đ−ợc chạy và yêu cầu dữ liệu từ server, cơ chế của việc dành dữ liệu là khá giống với cách thức của ứng dụng web truyền thống .
2. 2 Web server MVC
Nhìn chung, các ứng dụng web đã quá quen với mô hình MVC. Một ứng dụng web tạo ra một số tách biệt giữa giữa View và Model, do chúng nằm trên các máy khác nhau. Tuy nhiên ta có thể viết một ứng dụng web mà có khả năng kết hợp các mô hình này với nhau, tại một số điểm nhất định.
Hầu hết các thành phần của MVC trên Web thực hiện xử lý trang HTML, và ch−ơng trình mà tạo ra nó ( ví dụ là View ) khác xa so với những gì ng−ời dùng thực sự nhìn thấy khi trang này yêu cầu. Trong tr−ờng hợp một ứng dụng Ajax cung cấp dữ liệu cho một client JavaScript, View từ ứng dụng này chính là tài liệu XML sẽ đ−ợc trả về cho client d−ới dạng đáp ứng HTTP.
Hình 2.9:Cách thức thực hiện một yêu cầu qua mạng
2.2.1 Các vấn đề nảy sinh với khả năng sử dụng lại các đoạn kịch bản.
Trong các ứng dụng web, các thành phần của một ứng dụng th−ờng đ−ợc lặp đi lặp lại. Với Ajax, công việc của ta đơn giản chỉ là sử dụng lại các đoạn kịch bản đã có sẵn. Tuy nhiên khi áp dụng các đoạn kịch bản khác nhau
vào những vị trí khác nhau trong một ứng dụng cũng gặp một số vấn đề nảy sinh. Bao gồm:
- V−ớng mắt với hàng đợi SQL trong trang. Nếu muốn tìm kiếm theo loại hoặc từ khoá, cần phải thay đổi lại việc tạo SQL. Ta có thể phải chịu một tập trạng thái if tích luỹ qua thời gian khi chúng ta càng thêm nhiều chức năng tìm kiếm, và tất nhiên số l−ợng các tham số tìm kiếm sẽ tăng lên.
- Gặp khó khăn với dạng dữ liệu XML trong trang. Có một vài lý do tại sao ta muốn thay đổi dạng dữ liệu.
- Khó khăn với cơ sở dữ liệu đ−ợc sử dụng để tạo ra XML. Do ta duy trì một cơ sở dữ liệu kết nối mở mọi lúc khi đang tạo XML, nên sẽ không có bất cứ thao tác gì phức tạp trong vòng lặp while(), vì thế kết nối sẽ không đ−ợc lâu, thậm chí còn xuất hiện hiện t−ợng thắt cổ chai. Cũng nh− vậy, cơ sở dữ liệu để tạo XML chỉ làm việc khi và chỉ khi ta xử lý cơ sở dữ liệu của chúng ta giống nh− là cấu trúc dữ liệu phẳng.
2.2.2. Refactoring lại mô hình
Để giải quyết những v−ớng mắc trên, chúng ta thực hiện việc quản lý cơ sở dữ liệu thông qua các mô hình quan hệ đã đ−ợc chuẩn hoá. Các dữ liệu cũng nh− mối quan hệ giữa chúng đ−ợc xử lý thông qua các công cụ định bản đồ quan hệ-đối t−ợng. Chúng ta có các công cụ ORM (Object Relational Mapping). Một ORM tự động dịch giữa cơ sở dữ liệu và các đối t−ợng trong bộ nhớ, thực hiện quản lý cơ sở dữ liệu SQL. Các nhà lập trình PHP thích PEARDB_DataObject, Easy PHP Data Object (EZPDO) hoặc Metastorage. Các nhà lập trình Java thích .NET.
2.2.3. Chia tách nội dung từ thể hiện
Trong tr−ờng hợp chúng ta phải duy trì nhiều trang web, nếu chúng ta muốn thay đổi định dạng XML tại một vị trí thì chúng ta phải thay đổi cho
mọi nơi. Trong tr−ờng hợp phức tạp hơn, nếu chúng ta muốn duy trì nhiều định dạng, trong đó một cho danh sách ngắn và danh sách chi tiết để mô tả các khách hàng và định dạng khác cho ứng dụng stock, khi đó chúng ta muốn định nghĩa từng dạng một và cung cấp một bản đồ trung tâm cho chúng.
Một h−ớng tiếp cận thông dụng là ngôn ngữ tạm thời, là hệ thông mà chấp nhận tài liệu text chứa một số các markup mà hoạt động nh− là nơi chứ các biến thực trong suốt quá trình thực hiện. PHP, ASP, và JSP là những ngôn ngữ tạm thời, đ−ợc viết nh− là nội dung của trang web với mã đ−ợc nhúng, khác với mã mà nội dung đ−ợc nhúng nhìn thấy trong một Java servlet hoặc là kịch bảng CGI truyền thống. Mặc dù vậy ta thấy ngôn ngữ kịch bản có tác dụng với trang web, nhờ đó dễ dàng thể hiện.
Ng−ợc lại với các ngôn ngữ xây dựng tức thời nh− PHP Smarty và Apache Velocity (một hệ thống dựa vào Java và .NET), có nhiều giới hạn về khả năng của mã, th−ờng giới hạn điều khiển luồng và các lệnh về vòng lặp.
Ch−ơng III. Các kỹ thuật chính trong thiết kế ứng dụng
I. Các mô hình của MVC
Trong mô hình MVC, Model là mô hình trên server, View là là nội dung đ−ợc tạo ra mà gửi tới client, và Controller là tập định nghĩa các trang hoặc một servlet của ứng dụng. Về nguyên gốc thì MVC đ−ợc phát triển cho các ứng dụng máy tính để bàn. Tuy nhiên nó đ−ợc sử dụng ở nhiều vị trí trong một ứng dụng Ajax.
1.1 MVC dùng trong mô hình lặp
Một mô hình MVC web cơ bản mô tả toàn bộ ứng dụng một cách chi tiết. Toàn bộ luồng dữ liệu đ−ợc tạo ra là View. Toàn bộ lớp CGI hoặc servlet là Controller.
Trong phát triển ứng dụng desktop, các mô hình MVC th−ờng đ−ợc áp dụng với quy mô vừa phải. Tuy nhiên trong một vài tr−ờng hợp đơn giản nh− widget button, ng−ời ta cũng sử dụng MVC.
- Việc thể hiện các trạng thái trong nh− ấn, không ấn, không hoạt động- là Model. Một Ajax widget sẽ sử dụng các trạng thái này nh− là một đối t−ợng JavaScript.
- Một widget đ−ợc biểu diễn trên màn hình hợp thành các nốt DOM, trong tr−ờng hợp của giao diện ng−ời dùng Ajax, có thể thay đổi đ−ợc trạng thái, độ t−ơng phản… là View.
- Đoạn ch−ơng trình liên quan tới cả 2 là Controller. Đoạn mã quản lý (xuất hiện trong ứng dụng lớn khi ng−ời sử dụng ấn ) cũng là Controller, nh−ng nó không phải là Controller cho View và Model.
Hình 2.10 mô tả MVC đ−ợc ứng dụng cho một widget cây. Model bao gồm các node cây, mỗi node là một danh sách các node con, các trạng thái đóng/mở, và một vài đối t−ợng công việc, t−ơng ứng với các file và các th− mục trong một file explorer. View bao gồm các biểu t−ợng và các đ−ờng kẻ đ−ợc vẽ trên các canvas widget. Phần điều khiển quản lý các sự kiện ng−ời dùng( nh− là đóng mở các node và thể hiện các menu popup) thực hiện cập nhật các yêu cầu cho các node cụ thể, cho phép View có khả năng tự làm t−ơi.
Hình 2.10:Mô hình MVC ứng dụng trong cấu trúc widget cây.
1.2 Sử dụng MVC tại trình duyệt
Nh− ta đã biêt, Model bao gồm 3 thành phần. Model bao gồm các đối t−ợng hoạt động, View là toàn bộ trang có thể lập trình, và bộ điều khiển là sự kết hợp của tất cả các bộ điều khiển sự kiện trong đoạn mã mà kết nối UI tới các đối t−ợng domain.
Hình 2.11:Mô hình MVC với các quy mô khác nhau trong kiến trúc ứng dụng.
II. View trong một ứng dụng Ajax
Đối với view, ta cần quan tâm tới 2 vấn đề: Chia tách View khỏi tính logic và Chia tách logic khỏi View. Từ vị trí của ứng dụng JavaScript đ−ợc chuyển tới trình duyệt khi ứng dụng đ−ợc khởi động, View là trang nhìn thấy đ−ợc, bao gồm các thành phần DOM mà đ−ợc viết bởi HTML. Theo MVC, View có 2 chức năng chính. Nó phải cung cấp một giao diện có thể nhìn thấy đ−ợc cho ng−ời sử dụng để thực hiện các sự kiện từ đó Nó cũng cần phải tự cập nhật t−ơng ứng với những thay đổi trong Model, th−ờng đ−ợc thông báo thông qua Controller.
Nếu nh− ứng dụng sẽ đ−ợc phát triển bởi một nhóm nào đó, View sẽ có thể là đối t−ợng của hầu hết các nội dung, bao gồm cả các nhà thiết kế, các nhà đồ hoạ cũng nh− các nhà lập trình. Nếu nh− yêu cầu các nhà thiết kế viết ch−ơng trình hoặc yêu cầu các nhà lập trình làm đồ hoạ cho một ứn dụng sẽ là một ý t−ởng tồi. Thậm chí nếu nh− ta đang thực hiện cả 2 vai trò này, tốt nhất ta nên tách biệt ra.
Trong những phần tr−ớc, ta đã mô tả cách thức xây dựng các trang web của ta sao cho CSS, HTML và JavaScript đ−ợc định nghĩa thành các file riêng rẽ. Bản thân trang đ−ợc phân thành MVC, với stylesheet là View và HTML/DOM là mô hình ( Một mô hình đối t−ợng tài liệu) . Khi đó HTML và CSS đ−ợc xử lý giống nh− View. Việc tách biệt các nhà thiết kế và các nhà lập trình ra thành các thành phần với nhau vẫn là một ý t−ởng tốt. Với Ajax, công việc đó thực sự là dễ dàng, đơn giản ta chỉ việc chuyển JavaScript ra thành một file riêng.
2.1 Chia tách logic khỏi View
Để chia tác view, ta cần viết các kịch bản thành các file riêng rẽ. Chúng ta viết các điều khiển sự kiện JavaScript nh− sau:
onclick=’importData(“datafeed3.xml”,mytextbox.value);’/>
Khi đó ta đ−a logic công việc vào View. Với đoạn mã trên, datafeed3 là gì? và giá trị của mytextbox phải làm gì? Tại sao hàm importData có 2 hạng và chúng có ý nghĩa nh− thế nào? Ng−ời thiết kế không cần phải biết những thứ nh− vậy.
ImportData là một hàm logic. View và Model không cần thiết phải nói chuyện trực tiếp với nhau. Vì vậy, ta có thể xử lý việc chia tách bằng cách sử dụng một lớp gián tiếp. Khi đó ta viết lại đoạn mã trên nh− sau:
<div class=’importButton’ onclick=’importFeedData()’/>
và định nghĩa một điều khiển sự kiện nh− sau:
Function importFeedData(event) {
importData(“datafeed3.xml”,mytextboxt.value); }
khi đó các hạng phù hợp với hàm importFeedData hơn là một điều khiển sự kiện dị bộ. Nh− vậy ta có thể sử dụng lại hàm này tại bất cứ vị trí nào.
Để duy trì trạng thái tách biệt giữa Controller và View,ta có thể truy cập sự kiện tự động. Thay vì khai báo một điều khiển sự kiện, ta chỉ định một marker của một vài phần mà sẽ đ−ợc thực hiện bởi đoạn mã. Ta có một vài chức năng cho marker này. Ta thêm vào một ID thống nhất cho một thành phần và chỉ định các điều khiển sự kiện trên một cơ sở nào đó (thành tố). Khi đó HTML sẽ đ−ợc viết lại nh− sau:
<div class=’importButton’ id=dataFeedBtn’>
và đoạn mã phía sau hoạt động nh− là một phần của hàm gọi ng−ợc window.onload. Ví dụ :
var dfBtn=document.getElementById(‘dataFeedBtn’); dfBtn.onclick=importFeedData;
Nếu nh− chúng ta muốn thực hiện cùng một hoạt động trên nhiều điều khiển sự kiện, chúng ta cần cung cấp một marker không đồng nhất. Cách đơn giản nhất là định nghĩa thêm một lớp CSS.
2.2 Chia tách View khỏi logic.
ở phần trên ta đã thực hiện công việc sao cho các nhà thiết kế có thể phát triển trang web mà không phải quan tâm đến mã ch−ơng trình. Tuy vậy vẫn còn một số hàm của ứng dụng vẫn đ−ợc nhúng vào trong HTML, ta th−ờng gọi là các khoá. Các khoá này đ−ợc định nghĩa là các tag DIV, và các nhà thiết kế có thể xoá một vài khoá nếu nh− không chú ý.
Điều quan trọng ở đây là ta có thể thay đổi các khoá này thông qua việc tạo ra một vài DOM cho chúng, thay vì khai báo chúng trong HTML. Hơn nữa do ta có thể có nhiều bản sao của cùng một loại trên một trang web, nếu ta không muốn các nhà thiết kế thay đổi trình tự của các khoá, ta có thể khai báo mỗi Div tag thành một lớp, khi đó ta có thể quản lý chúng một cách dễ dàng.
III. Bộ điều khiển trong ứng dụng của Ajax
Vai trò của bộ điều khiển trong MVC là hoạt động giống nh− thành phần trung gian giữa Model và View. Trong một ứng dụng GUI nh− là ứng dụng client Ajax, lớp điều khiển chứa các điều khiển sự kiện. Với các trình duyệt web, th−ờng có 2 mô hình sự kiện khác nhau.
3.1 Điều khiển sự kiện JavaScript truyền thống
Trong các trình duyệt web, ứng dụng JavaScript cho phép chúng ta định nghĩa đoạn mã sẽ đ−ợc thực hiện để phản hồi lại một sự kiện của ng−ời dùng( ví dụ nh− là các sự kiện bấm chuột hoặc bàn phím.). Với các trình duyệt web có hỗ trợ Ajax, những điều khiển sự kiện có thể đ−ợc đăng ký cho hầu hết các
thành phần. Ta có thể sử dụng các điều khiển sự kiện để kết nối các giao diện ng−ời dùng (ở đây là View) với mô hình đối t−ợng.
Các thành tố DOM có một số l−ợng nhỏ các đặc tính đ−ợc định nghĩa từ tr−ớc mà ở đó các hàm trả về có thể đ−ợc đăng ký. Ví dụ, để thêm một hàm mà sẽ đ−ợc gọi khi kích chuột vào thành phần myDomElement, ta có thể viết nh− sau:
MyDomElement.onclick=showAnimatedMonkey
trong đó myDomElemenr là một thành phần DOM mà ta có điều khiển hàm. Show-AnimatedMonkey là một hàm, đ−ợc định nghĩa nh− sau:
Function showAnimatedMonkey(){}
đây là một hàm JavaScript nguyên thuỷ. Cần chú ý rằng khi đăng ký điều khiển sự kiện, ta thực hiện chuyển đối t−ợng hàm, không phải là gọi tới đối t−ợng đó, vì nó không có không có tham số sau phần tên hàm. Đây là một lỗi th−ờng mắc phải:
MyDomElement.onclick=showAnimatedMonkey()
Thoạt nhìn nó giống nh− cách xử lý những hàm thông th−ờng với những đối t−ợng lớp thứ nhất. Tuy vậy nó sẽ không thực hiện những gì chúng ta mong muốn. Hàm sẽ đ−ợc gọi khi chúng ta thực hiện một đăng ký chứ không phải khi kích vào thành phần DOM. Đặc tính onclick sẽ đ−ợc thiết lập cho bất cứ thứ gì do hàm trả về. Trừ khi ta thực hiện theo một cách khác liên quan tới các hàm mà trả về chuẩn cho các hàm khác. Đây là cách thức khai báo đúng:
MyDomElement.onclick=showAnimatedMonkey;
Khai báo này trả về một giá trị chuẩn cho hàm gọi ng−ợc tới thành phần DOM của ta, nói rằng đây là hàm liên quan tới việc khi node đ−ợc kích. Các thành phần DOM có rất nhiều những đặc tính mà ở đó có các hàm điều khiển sự kiện có thể đ−ợc tiếp cận. Các hàm gọi ng−ợc điều khiển sự kiện thông th−ờng cho công việc GUI đ−ợc đ−a ở bảng d−ới. Các đặc tính t−ơng tự cũng có thể tìm thấy đ−ợc trong trình duyệt web JavaScript. Hàm
XMLHttpRequest.onreadystate và hàm window.onload cũng là các hàm điều khiển sự kiện mà có thể đ−ợc đăng ký bởi ng−ời lập trình.
Chúng ta đã có một điều khiển trên một đối t−ợng DOM, và đã đăng ký một hàm gọi ng−ợc cho đặc tính onclick. Khi một đối t−ợng DOM nhận đ−ợc tín hiệu kích chuột thì sẽ liên quan tới hàm gọi ng−ợc. Mặc dù vậy nội dung của hàm sẽ đ−ợc đăng ký cho node DOM mà nhận sự kiện này. Phụ huộc vào vị trí và cách thức của hàm đ−ợc khai báo, cách thức đăng ký trên có thể dẫn đến sự lộn xộn.
Để làm rõ vấn đề này, ta sẽ tìm qua một ví dụ. Ta định nghĩa một lớp