Van Thoai Nguyen's Blog - Chia sẽ những kĩ thuật lập trình .NET

- Theo tin trên blog của bác ScottGu thì JQuery trong tương lai sẽ được ship cùng với .NET IDE của Microsoft. Phiên bản MVC Preview5 cũng mới được cho ra lò. Bản thân tui trước giờ vẫn thắc mắc là khi sử dụng MVC thì sẽ viết web Ajax như thế nào. Sau một lúc gu gồ, tui tìm thấy 1 link khá hay của bác Phil Haack. Vì nội blog entry đó chỉ giới thiệu 1 video podcast và không có code mẫu nên tui quyết định làm theo hướng dẫn và viết một entry cuối cùng trong tháng 9 thân yêu .

- Trong bài viết này, tui sẽ làm y chang hướng dẫn của bác Phil Haack. Như chúng ta biết, thì AJAX là chữ viết tắt của “Asynchronous JavaScript and XML”. Như vậy ta có thể làm một trang web có AJAX bằng cách kết hợp JavaScript với các WebService. Một trong những mục đích của AJAX là tránh postback về phía server khi thực hiện các thao tác đơn giản. Trường hợp điển hình nhất là những Quick Reply của các forum. Khi bạn trả lời một bài viết nào đó vào ô text box Quick Reply rồi click vào nút gửi đi, nội dung bạn đánh vào sẽ được lưu vào database, phần HTML hiển thị reply của bạn sẽ hiện ra ngay sau bài viết mới nhất và những gì bạn đánh vào text box sẽ bị xóa đi. Đó làm một chức năng AJAX điển hình mà ta có thể code bằng tay được.

- Nếu là tui, tui sẽ implement một webservice để nhận request save xuống database nội dung bài post khi người ta reply. Kết tiếp viết một số hàm JavaScript đơn giản để hiển thị thêm phần nội dung HTML trả lời vào dưới cùng của bài viết và xóa trắng text box nếu cần thiết. Và thật sự đó là cách tui làm ở cty trước, khi implement chức năng reply post cho trang web www.cofieu.com.vn/news. Khi đó tui chưa sử dụng JQuery nên đã code hơi trâu bò một cách không cần thiết, trong khi những gì tui cần để select các DOM object trong HTML đã được JQuery hỗ trợ hết. Cái thật sự cần làm là WebService để thực hiện request từ phía client.

- Để tóm tắt, tui xin trình bày cách mà bác Phil Haack đã sử dụng. Trong video podcast của bác Phil không cần implement một WebService mới mà chỉ implement một hàm Action, trả về một JSON object. Và ta sẽ phải viết một số hàm JavaScript đơn giản, nhận data đó , kết hợp với JQuery để update HTML vào chỗ thích hợp. Ý tưởng là vậy, ta sẽ bắt tay vào làm demo đó như sau:

- Trước hết để thực hiện được demo này, các bạn đã install .NET Framework 3.5 SP1, VS.NET 2008 SP1, Asp.net MVC Preview 5 Codeplex. Nếu chưa có chịu khó gu gồ nhe .

- Trong tương lai thì các file js của thư viện JQuery sẽ được include sẵn mỗi khi mình tạo project web. Còn hiện nay MVC vẫn còn đang thử nghiệm nên chúng ta chịu khó download 2 file js ở các link sau về để include vào trong project:
Link 1: jquery-1.2.6.js
Link 2: jquery.color.js

- Sau khi đã install và download những thứ cần thiết, bạn hãy mở VS.NET 2008, tạo mới 1 project web ASP.NET MVC. Kéo 2 file js vừa download vào thư mục Content như hình:

Hình 1: Thêm jquery vào project

- Mở file Site.Master để include hai file đó vào website. Các bạn có thể kéo thả cho lẹ Hình 2: Thêm jquery vào master page

- Để thử cách viết Controller của MVC, ta hãy tạo mới một Controller khác và không đụng đến các Controller có sẵn khi tạo ra Project web. Như vậy ta sẽ tạo ra một trang mới là TestAjax/Main.aspx, và Controller tương ứng cho View này sẽ là TestAjaxController:
Hình 3: Thêm View và Controller

- Trong file Main.aspx, chúng ta sẽ thêm vào 2 span với id lần lượt là name và url để hiển thị thông tin nhận được khi request. Ta cũng sẽ tạo một button với sự kiện onClick ứng với hàm JavaScript ShowInformation() mà ta sẽ implement sau. Còn bây giờ hãy xem đại khái HTML của file Main.aspx:
Hình 4: Html của View

- Như vậy hàm JavaScript ShowInformation sẽ thực hiện việc Request lên server, sau đó nhận data từ server trả về và cập nhận html cho 2 thẻ span phía trên. Nội dung của hàm JavaScript như sau:
Hình 5: Code javascript của hàm ShowInformation

- Giải thích: Hàm ShowInformation sẽ request đến address “TestAjax/GetInformation để lấy dữ liệu. Request này sẽ được thực thi bởi hàm GetInformation trong class TestAjaxController . Theo đúng convention của ASP.NET MVC:


- Điều đáng lưu ý là function này là nó tạo ra 1 Annonymouse Object và wrap trong một JSonResult Type để trả về cho client. Như ta thấy trong hình thì Anonymouse Object này sẽ có 2 properties là Message1 và Message2 và 2 field này được sử dụng trong hàm JavaScript ở trên. (Anonymous Object là 1 feature mới của .NET Framework 3.x)

- Cuối cùng tui có thêm vào một hàm JavaScript để tạo hiệu ứng đẹp mặt như hướng dẫn trong video podcast. Tóm lại nếu mới tìm hiểu ASP.NET MVC và chưa biết nó support AJAX tới đâu nhưng ta chắc chắn rằng sẽ có cách để làm những hiệu ứng AJAX rất nhanh và dễ dàng nhờ vào JQuery.


- Demo của tui http://nthoaiblog.googlepages.com/SampleMvcPreview5AjaxJQuery.zip

http://nthoaiblog.googlepages.com/SampleMVCRCAjaxJQuery.zip (MVC Release Candidate)

- Để có thể tạo được project web ASP.NET với mô hình MVC framework, các bạn phải download ASP.NET MVC Preview 3 Visual Studio Templates và chỉ có thể cài được khi bạn đã có VS.NET 2008 hoặc VS.NET Express 2008. Đối với những bạn chỉ có VS.2005 trong máy thì thật là bực mình vì … làm biếng đi mua đĩa VS.2008 mà lại muốn test ngay xem MVC trong ASP.NET như thế nào. Đối với một số người thì không thể có VS.NET 2008 để sử dụng vì bản quyền. Tôi đã táy máy để chuyển những template từ trang CodePlex để có thể install và chạy được với VS.NET 2005.

Bạn có thể download template cho VS.NET 2005 ở link sau:

1st mirror: ASPNET_MVC_Project_Template_for_VSNET_2005.html


Hoặc ở link sau


2nd mirror: ASPNET_MVC_Project_Template_for_VSNET_2005.html



Tuy nhiên có một số điều lưu ý:

- Nếu bạn vừa cài VS.NET 2005 và VS.NET 2008 thì tất nhiên cũng chẳng cần install cái setup của tôi làm gì. Khi bạn cài bản template của Codeplex, các template mặc định sẽ được chép vào các thư mục của VS.NET 2005 và mặc định cả 2 version đều có thể hiểu được các template này. Tuy nhiên template của CodePlex sẽ không chạy được cho VS.NET 2005 vì project được tạo ra từ template này chỉ hiểu được trên VS.NET 2008 (cú pháp C# 3.0). Vì vậy nếu như bạn muốn install phiên bản riêng cho VS.NET 2005 thì hãy bỏ check các Item Template và chỉ chọn install 2 project template ở cuối cùng như trong hình. Nếu bạn vẫn chọn và install, trình install sẽ hỏi bạn có chép đè file có sẵn từ lần install trước hay không, và bạn có thể chép đè vẫn không sao vì các item template có thể hiểu được trên cả VS.NET 2005 và VS.NET 2008.

Hình 1: Bạn có thể chọn những mục để install.

- Tôi đã chỉnh sửa một số nơi trong template gốc của CodePlex để project tạo ra có thể build được trên VS.NET 2005 cụ thể là sửa trong file global.asax.cs. Trong phần routing ở VS.NET 2008 có hỗ trợ các extension API mà VS.NET 2005 không thể hiểu được buộc lòng tôi phải đổi sang kiểu code truyền thống:



Hình 2: Đổi sang kiểu code truyền thống để có thể build.

- Và sau khi install xong, các bạn sẽ thấy các template mới khi muốn tạo project mới:


Hình3: Project templates sau khi install



Trong mấy ngày tới, tôi sẽ nghiên cứu và chế ra cái template có sẵn Unit Test.

- Ai từng sử dụng qua ngôn ngữ ASP cũng biết rằng khá bất tiện khi phải xử lý code giao diện chung với những xử lý bussiness logic. Những xử lý để đọc dữ liệu database viết xen kẽ với những phần code định dạng HTML làm cho ứng dụng web rất khó bảo trì và khó tái sử dụng. Sau khi version 4.0 của IIS ra đời năm 1997, Bác Bill cùng các đồ đệ tiếp tục nghiên cứu một mô hình web application để giải quyết vẫn đề trên của ASP: tách rời giữa phần hiển thị và phần nội dung. Sau 4 năm nghiên cứu với một loạt những phiên bản beta ở các năm 2000 và 2001, ASP.NET 1.0 đã được công bố vào tháng 1 năm 2002, sau đó là version 1.1 ở tháng 4 năm 2003. Mô hình code-behind của ASP.NET đánh dấu một bước tiến so với người anh em ASP, nó khuyến khích người viết web trên nền .NET xây dựng những ứng dụng với sự tách bạnh rõ ràng giữa các thành phần hiển thị và nội dung mặc dù vẫn có thể viết theo style của ASP, mọi xử lý viết thẳng vào file aspx, ascx. Trên lý thuyết, mô hình này sẽ giúp những web designer chủ động thiết kế ra giao diện của ứng dụng mà không sợ ảnh hưởng đến những phần code xử lý bên dưới. Điều này dường như giống với ý tưởng tách rời giữa controller và view trong mô hình Model-View-Controller framework.

- Trong một số bài viết về cách implement MVC cho ASP.NET, các tác giả thường cho rằng Code Behind của 1 trang ASP.NET là controller, các file aspx, ascx chính là các View. Theo tôi điều này chỉ đúng một phần vì các nguyên nhân sau:

1/Với mô hình Code Behind, đúng là đã có sự tách riêng giữa phần hiển thị (aspx, ascx) và các xử lý bussiness logic. Tuy nhiên người lập trình chỉ có thể làm được chuyện tách riêng phần View và Controller. Trong khi phần Model nếu không làm khéo sẽ vẫn dính chặt với vần controller và chẳng dễ test nó chút nào. Nếu bạn viết code lấy dữ liệu từ database ngay trong file code behind của 1 trang thì rõ ràng Model và Controller của bạn dính thành 1 cục và không thể test được bằng Unit Test. Như vậy người không biết sẽ vô tình làm code của mình khó test, khó bảo quản và khó sử dụng lại.

2/Các lớp Code Behind của ASP.NET đều kế thừa từ System.Web.Page, như vậy controller theo kiểu này cũng không thể dùng Unit Test để test các xử lý bussines logic. Đó là điều mà các fan của Unit Test không thể chấp nhận được. Ngoài ra, với sự phụ thuộc vào namespace System.Web như vậy, những xử lý của bạn sẽ không thể sử dụng lại khi muốn đổi một ứng dụng web sang ứng dụng windows form.

- Ngoài các lý do trên, có 1 điều nữa giúp tôi khẳng định Mô hình Code Behind của ASP.NET không theo MVC, đó chính là sự ra đời của framework ASP.NET MVC gần đây và một số framework MVC khác cho ASP.NET.

- ASP.NET MVC Framework là một Model-View-Controller framework được Microsoft thêm vào bộ ASP.NET. Nó cho phép người làm phần mềm xây dựng những Web application theo ý tưởng của MVC, gồm 3 thành phấn Model, View và Controller. Một Model tượng trưng cho một trạng thái của ứng dụng. Thông thường, một model sẽ maps với một table trong cơ sở dữ liệu, những record trong table đó sẽ tượng trưng cho trạng thái của table đó. Còn một Controller sẽ handle những tương tác của người dùng với ứng dụng và cập nhật giá trị cho Model. Một View sẽ lấy những dữ liệu cần thiết của Model và hiển thị ra giao diện.




- ASP.NET MVC Framework tách rời các models, các views và các controllers của MVC bẳng cách dùng các Interface (trong ngôn ngữ lập trình), bằng cách đó giúp cho các thành phần này có thể test độc lập với nhau. View engine trong ASP.NET MVC framework chính là các trang aspx, ascx để hiển thị giao diện. Tuy nhiên, những tương tác của người dùng lên trang web sẽ được truyền thẳng cho controller mà không thông qua cơ chế postback truyền thống. Với ASP.NET MVC framework, chúng ta còn có thể làm được 1 trang web với Friendly-URL mà không phải mất công code những implement phức tạp như trước đây. ASP.NET MVC Preview 3 Release vừa mới được công bố hồi tháng 5/2008 với nhiều feature mới hứa hẹn nhiều điều hấp dẫn để tìm hiểu cho những lập trình viên như chúng ta.

- Mấy tuần nay tôi đang tìm hiều về các pattern thiết kế giao diện và đã gặp nhiều vướng mắc. Một số đã tự giải quyết được, một số vẫn còn tồn đọng. Vì vậy tôi cũng muốn chia sẽ những gì mình đã tìm hiểu với mọi người. Tôi quyết định dịch và viết bài từ mô hình ra đời lâu nhất và được nhiều người biết đến nhất, đó là mô hình MVC. Ban đầu tôi đã định không tìm hiểu về MVC và đi vào những thiết kế mới nhất như MVP nhưng thực ra MVC vẫn còn rất phổ biến hiện nay. (Cám ơn Tính nai oan oan cho các thông tin về MVC và Monorail) Vì vậy, trong những loạt bài sau tôi sẽ viết nhiều về pattern đang phổ biến hiện nay như MVP và các ví dụ thực tế của nó. Phần lớn sẽ là bài dịch và sửa đổi cho dễ hiểu, hiện nay vẫn chưa đủ trình độ để sáng tạo cái gì cả.

- Có thể nói rằng các chương trình dù là Win Application hay Web Application đều gồm hai thành phần chính là giao diện và dữ liệu. Các ứng dụng chúng ta tạo ra sẽ đọc dữ liệu từ nơi lưu trữ và hiển thị lên cho người dùng thấy. Sau khi người sử dụng chương trình thao tác với ứng dụng và thay đổi giá trị dữ liệu, chương trình sẽ lưu các thay đổi đó xuống nơi lưu trữ. Do luồng thông tin chính của các ứng dụng sẽ truyền từ nơi lưu trữ lên trên phần hiển thị và ngược lại nên người có thể cho rằng nên có cách nào đó thiết kế hai thành phần dữ liệu và giao diện cùng với nhau để giảm thiểu việc coding và tăng performance. Dù không cố tình làm như vậy nhưng đa số những bạn mới viết chương trình cơ sở dữ liệu lần đầu tiên thường không biết nên sẽ làm theo cách này. Cách làm như vậy có một số vấn đề nghiêm trọng. Một trong các vấn đề đó là việc giao diện thường có xu hướng thay đổi nhiều hơn so với dữ liệu lưu trữ. Hơn nữa, những xử lý tính toán (business logic) trong chương trình cũng là một thành phần thường xuyên thay đổi trong suốt quá trình phát triển phần mềm. Nếu chương trình được xây dựng theo kiểu trộn lẫn code của các thành phần data access, business logic và presentation thì sẽ rất khó bảo trì sửa đổi cũng như khả năng sử dụng lại. Chính vì mục đích tăng tính độc lập giữa các thành phần trong ứng dụng và để giải quyết những trở ngại trên, người ta đã nghĩ ra nhiều mô hình và cách thiết kế ứng dụng rất hiệu quả. Kể từ những năm 70, mô hình MVC được nghĩ ra để giải quyết một số vấn đề trên.

Đặt vấn đề:

- Khi lần đầu tiên viết chương trình đọc dữ liệu từ database và hiển thị lên form, tôi đã viết chương trình kiểu gom chung phần xử lý giao diện và truy xuất dữ liệu làm một. Có nghĩa là tôi tạo ra câu query sql ngay trong code của lớp giao diện. Cách làm này rất không hợp lý vì khi sửa đổi cấu trúc bảng trong cơ sở dữ liệu thì câu query sql sẽ cần phải đổi, dẫn đến phải sửa lớp giao diện. Khi cần đổi database khác thì gần như phải viết lại từ đầu. Như vậy gom chung giữa giao diện và dữ liệu là không nên, và ai cũng biết điều đó.

- Liệu có một cách nào chúng ta có thể chia nhỏ chương trình thành nhiều module để tiện thay đổi, bảo trì?


Giả sử người ta có các yêu cầu sau:

- Giao diện của ứng dụng có xu hướng thay đổi nhiều hơn là những thay đổi business logic của chương trình, đặt biệt đối với những ứng dụng Web. Ví dụ như cùng một trang Web hiển thị sản phẩm có thể sẽ được yêu cầu thay đổi nhiều lần về cách bố trí sản phẩm, màu sắc bố cục trong khi cách để lấy thông tin sản phẩm từ database sẽ không cần sửa đổi. Hơn nữa, một trong những tiện lợi của ứng dụng Web là người ta có thể thay đổi giao diện vào bất cứ lúc nào mà không cần người dùng phải install cài đặt gì cả. Nếu như những đoạn code xử lý giao diện và xử lý business logic bên trong chương trình được viết chung với nhau, bạn sẽ phải thay đổi những lớp dùng để xử lý business logic mỗi khi cần thay đổi giao diện. Mà khi xử lý business logic của ứng dụng bị thay đổi thì có thể sẽ gây ra các lỗi không mong muốn nên phải test mọi thứ lại từ đầu cho dù đó chỉ là một thay đổi nhỏ về giao diện. Như vậy ta có một nhu cầu về việc tách riêng giữa giao diện và các xử lý business logic.

- Trong một số ứng dụng, chương trình sẽ hiển thị cùng một dữ liệu bằng nhiều cách khác nhau. Ví dụ như chúng ta cần làm một loạt các biểu đồ khác nhau hiển thị giá chứng khoán, các biểu đồ này được hiển thị cùng lúc. Nếu người dùng thay đổi dữ liệu trên một màn hình nào đó thì hệ thống phải cập nhật thay đổi đó trên các màn hình còn lại. Ta có một nhu cầu về tự cập nhật giao diện khi có những thay đổi trong dữ liệu.

- Để thiết kế giao diện HTML đẹp và hiệu quả cần những kĩ thuật đặt biệt, có khi cả năng khiếu về mĩ thuật mà không phải một lập trình viên nào cũng có được. Vì vậy trong những dự án lớn thường có những người design giao diện riêng và công việc của họ chỉ là thiết kế layout, còn lập trình viên sẽ thực hiện các xử lý business logic của ứng dụng. Do đó nhu cầu cho việc tách rời phần design giao diện và phần lập trình được đặt ra để tăng hiệu quả cho quá trình làm phần mềm.

- Có một yêu cầu khác được đặt ra như sau: những thao tác trên giao diện thông thường sẽ gồm có hai phần: hiển thị và cập nhật. Thành phần hiển thị sẽ lấy dữ liệu từ nơi lưu trữ, định dạng lại nếu cần thiết và hiển thị lên màn hình. Khi người sử dụng thực hiện một số thao tác, những gì thay đổi sẽ được thành phần cập nhật gọi thành phần xử lý business logic để cập nhật các thay đổi đó xuống nơi lưu trữ. Như vậy thành phần hiển thị sẽ tự nó thực hiện việc lấy thông tin, trong khi những thao tác của người dùng sẽ được xử lý bởi một thành phần khác.

- Trong các ứng dụng Web, khi bạn click vào một link trên 1 trang, một thao tác ứng với link đó sẽ được thực hiện đồng thời một trang mới sẽ được hiển thị. Trong nhiều trường hợp, trang web cần hiển thị sau cùng sẽ không liên quan trực tiếp đến thao tác được gọi khi click vào link ở trang trước. Ví dụ: trong những trang Web mua bán trực tuyến, khi muốn xem danh sách những món hàng mình muốn mua trước khi thanh toán, bạn sẽ click vào phần giỏ hàng. Một danh sách những món hàng sẽ hiện ra kèm với các link hoặc button xóa chúng khỏi giỏ hàng. Nếu bạn đổi ý và muốn bỏ đi một món nào đó thì bạn sẽ click vào link hoặc button tương ứng. Sau đó, giỏ hàng sẽ lại hiện ra với danh sách những món hàng mới mà không có món bạn vừa xóa. Vì vậy, ứng dụng phải hiển thị lại cùng 1 trang với cùng một danh sách nào đó sau khi thực hiện hai thao tác khác hẳn nhau trong cùng một HTTP request. Vậy có một yêu cầu là nhiều xử lý phức tạp sẽ được thực hiện trong cùng một request.

- Ngày nay, giao diện của một ứng dụng nên được độc lập với thiết bị. Nếu bạn muốn ứng dụng Web của mình có thể được hiển thị nhanh và đẹp trên các thiết bị di dộng thì bạn phải sửa đổi nhiều ở phần giao diện và chắc chắn là những business logic sẽ không cần thay đổi gì cả. Một sự tách biệt rõ ràng giữa hai thành phần này sẽ giúp bạn đạt được yêu cầu đó vài giảm thiểu những rủi ro khi phải thay đổi business logic do sai lầm khi thiết kế lúc đầu. Vậy dẫn đến yêu cầu về thiết kế ứng dụng để dễ dàng hỗ trợ nhiều dạng thiết bị khác nhau chứ không riêng gì máy tính.

- Và cuối cùng, để phần mềm của bạn có thể được test một cách toàn diện đôi khi không khả thi và rất mất thời gian. Hiện nay người ta có thể sử dụng Unit Test để test các lớp business logic nhanh chóng chính xác và tự động trong hầu hết trường hợp. Vì thế càng làm cho những xử lý tách rời khỏi phần giao diện sẽ giúp chương trình của bạn dễ viết code test hơn. Vậy yêu cầu thiết kế ứng dụng cho dễ test bằng code cũng được đặt ra.

MVC sẽ đạt được mọi yêu cầu trên:

- Mẫu thiết kế Model-View-Controlller (MVC) tách rời phần dữ liệu domain, module hiển thị và những xử lý thao tác của người dùng thành ba nhóm lớp (class) riêng biệt:

Model: là những gì liên quan đến dữ liệu của ứng dụng. Model sẽ chịu trách nhiệm thao tác trực tiếp với database như truy xuất, cập nhật, thêm mới. Model sẽ lấy thông tin và trả về cho View, nó cũng sẽ chịu trách nhiệm thông báo cho Controller những thay đổi dữ liệu nếu có. Bạn có thể xem Model bao gồm các lớp DAL (Data Access Layer) và các lớp Domain.

View: View sẽ chịu trách nhiệm hiển thị thông tin như tên của nó. Ta có thể xem View như các trang web, hoặc các form trong ứng dụng windows.

Controller: là những lớp sẽ lắng nghe những thao tác chuột và bàn phím từ người dùng, nó sẽ tác động đến Model và View để thay đổi khi cần thiết.

Hình dưới mô tả mối quan hệ giữa Model, View và Controller, Model sẽ không biết gì về View và
Controller.

Hình: MVC Class Structure

- Theo như hình trên thì ta thấy cả View và Controller đều phụ thuộc và có thể gọi đến Model. Tuy nhiên, Model lại hoàn toàn độc lập với View và Controller. Điều này là một trong những lợi ích chính của mô hình MVC khi tách rời các thành phần Model View và Controller. Sự độc lập của Model giúp chúng ta build và viết code test cho nó mà không ảnh hưởng hoặc phụ thuộc đến những lớp hiển thị. Ngoài ra, sự tách rời View và Controller ra hai nhóm lớp như trên là một thuận lợi thứ hai đối với những ứng dụng có nhiều người dùng. Ví dụ như trong một số cách làm, người ta có thể lập trình phần kiểm tra quyền (Role) ngay trong phần xử lý giao diện. Khi theo cách làm MVC, người ta sẽ phải tách riêng phần kiểm tra quyền ra khỏi phần hiển thị và nó hoàn toàn thuận lợi khi cần sửa đổi hoặc thêm những trang mới.

Những lợi ích về test khi áp dụng MVC

- Sự dễ dàng trong viết code test là một thuận lợi khi áp dụng MVC. Test những component của chương trình trở nên rất khó khăn khi chúng phụ thuộc chặt chẽ vào nhau, đặc biệt đối với những thành phần giao diện. Để test giao diện của một phần mềm, tất nhiên bạn phải qua các bước cài đặt và đôi khi điều đó trở nên rất mất thời gian khi chỉ để test một chức năng đơn giản. Tệ hơn khi xảy ra lỗi, chúng ta sẽ rất khó để phát hiện lỗi ở phần nào. Đó là lý do tại sao chia nhỏ các thành phần chức năng là một trong những chiều hướng chính của các thiết kế quan trọng. MVC chia nhỏ các vấn đề như lưu trữ, hiển thị và cập nhật dữ liệu thành 3 nhóm components, những component này có thể được test độc lập với nhau.

- Ngoài vấn đề về sự phụ thuộc, giao diện của phần mềm cũng rất phức tạp khi muốn test. Người ta thường sử dụng người thật để test giao diện, hoặc sẽ phải viết những script test để giả lập những thao tác của con người. Để viết những script này thường rất mất thời gian và phức tạp. MVC KHÔNG giải quyết được vấn đề về test giao diện, NHƯNG nó tách rời phần dữ liệu Model ra khỏi những xử lý hiển thị và cho phép MODEL có thể được test độc lập với phần hiển thị và điều đó sẽ giảm thiểu những test case liên quan đến giao diện.

Ý kiến của Nguyễn Thoại:

- Tôi đã không dịch và đưa vào những dạng biến đổi của mẫu MVC vào bài này vì không muốn các bạn cảm thấy rối thêm, cũng không đưa vào những lợi ích và giới hạn của MVC. Lợi ích thì tất nhiên đã được đề cập tới ở trên nên cũng không cần tổng kết lại làm gì, còn giới hạn chính là tính phức tạp. Cũng như những bài viết trước, các Pattern luôn phức tạp nhưng khi chịu khó một chút thì về sau sẽ được những lợi ích lớn.

- Các bạn có thể đặt câu hỏi: áp dụng MVC vô ASP.NET như thế nào. Có ví dụ code sample nào không. Xin thưa là có trang ví dụ ở đây, nhưng cá nhân tôi vẫn còn nghi ngờ tính đúng đắn của nó. Sắp tới, tôi sẽ viết thêm một số bài nữa liên quan đến việc áp dụng MVC trong.NET để tìm hiểu những vấn đề tôi còn nghi ngờ. Trong bài viết này không có ví dụ vì tôi sẽ dành phần code sample cho các bài sau. Hi vọng qua bài dịch này các bạn có được khái niệm MVC là cái gì, và lợi ích của nó như thế nào và khoan hãy nghĩ đến cách áp dụng. Cũng giống như những pattern khác (ở các bài viết sau), MVC được nghĩ ra với mục đích tách rời các thành phần quan trọng trong ứng dụng để tăng tính dễ bảo trì, dễ test tự động và khả năng sử dụng lại. Cùng một mục đích như vậy nhưng các mẫu pattern khác như MVP sẽ có cách thực hiện và cách cài đặt khác.


Liệu mô hình ASP.NET của Microsoft với các trang aspx và code behind tách rời có phải là một implement MVC? Ở bài sau tôi sẽ trả lời câu hỏi đó và giới thiệu khái quát về một framework MVC Framework cho ASP.NET.