Happy new year 2009

Đón Trâu , tiễn Chuột .•*:•. Chúc ông, chúc bà .•*:•. Chúc cha, chúc mẹ .•*:•. Chúc cô, chúc cậu .•*:•. Chúc chú, chúc dì .•*:•. Chúc anh, chúc chị .•*:•. Chúc luôn các em .•*:•. Chúc cả các cháu .•*:•. Dồi dào sức khỏe .•*:•. Có nhiều niềm vui .•*:•. Tiền xu nặng túi .•*:•. Tiền giấy đầy bao .•*:•. Đi ăn được khao .•*:•. Về nhà người rước .•*:•. Tiền vô như nước .•*:•. Tình vào đầy tim .•*:•. Chăn ấm, nệm êm .•*:•. SUNG SƯỚNG BAN ÐÊM .•*:•. Hạnh phúc ban ngày .•*:•. Luôn luôn gặp may .•*:•. hO^” hO^”!!!

MVC Model View Controller

(Bài viết được sưu tầm – Tác giả Nguyễn Thoại) 

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

ASP.NET và MVC Framework

- 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ô hình MVC

Bắt đầu vào những năm 70 của thế kỷ 20, tại phòng thí nghiệm Xerox PARC ở Palo Alto. Sự ra đời của giao diện đồ họa (Graphical User Interface) và lập trình hướng đối tượng (Object Oriented Programming) cho phép lập trình viên làm việc với những thành phần đồ họa như những đối tượng đồ họa có thuộc tính và phương thức riêng của nó. Không dừng lại ở đó, những nhà nghiên cứu ở Xerox PARC còn đi xa hơn khi cho ra đời cái gọi là kiến trúc MVC (viết tắt của Model – View – Controller).

Trong kiến trúc MVC, một đối tượng đồ họa (GUI Component) bao gồm 3 thành phần cơ bản: Model, View, và Controller. Model có trách nhiệm đối với toàn bộ dữ liệu cũng như trạng thái của đối tượng đồ họa. View chính là thể hiện trực quan của Model, hay nói cách khác chính là giao diện của đối tượng đồ họa. Và Controller điều khiển việc tương tác giữa đối tượng đồ họa với người sử dụng cũng như những đối tượng khác.

Khi người sử dụng hoặc những đối tượng khác cần thay đổi trạng thái của đối tượng đồ họa, nó sẽ tương tác thông qua Controller của đối tượng đồ họa. Controller sẽ thực hiện việc thay đổi trên Model. Khi có bất kỳ sự thay đổi nào ở xảy ra ở Model, nó sẽ phát thông điệp (broadcast message) thông báo cho View và Controller biết. Nhận được thông điệp từ Model, View sẽ cập nhật lại thể hiện của mình, đảm bảo rằng nó luôn là thể hiện trực quan chính xác của Model. Còn Controller, khi nhận được thông điệp từ Model, sẽ có những tương tác cần thiết phản hồi lại người sử dụng hoặc các đối tượng khác.

Lấy ví dụ một GUI Component đơn giản là Checkbox. Checkbox có thành phần Model để quản lý trạng thái của nó là check hay uncheck, thành phần View để thể hiện nó với trạng thái tương ứng lên màn hình, và thành phần Controller để xử lý những sự kiện khi có sự tương tác của người sử dụng hoặc các đối tượng khác lên Checkbox. Khi người sử dụng nhấn chuột vào Checkbox, thành phần Controller của Checkbox sẽ xử lý sự kiện này, yêu cầu thành phần Model thay đổi dữ liệu trạng thái. Sau khi thay đổi trạng thái, thành phần Model phát thông điệp đến thành phần View và Controller. Thành phần View của Checkbox nhận được thông điệp sẽ cập nhật lại thể hiện của Checkbox, phản ánh chính xác trạng thái Checkbox do Model lưu giữ. Thành phần Controller nhận được thông điệp do Model gởi tới sẽ có những tương tác phản hồi với người sử dụng nếu cần thiết.

Kiến trúc MVC đã tách biệt (decoupling) sự phụ thuộc giữa các thành phần trong một đối tượng đồ họa, làm tăng tính linh động (flexibility) và tính tái sử dụng (reusebility) của đối tượng đồ họa đó. Một đối tượng đồ họa bấy giờ có thể dễ dàng thay đổi giao diện bằng cách thay đổi thành phần View của nó trong khi cách thức lưu trữ (Model) cũng như xử lý (Controller) không hề thay đổi. Tương tự, ta có thể thay đổi cách thức lưu trữ (Model) hoặc xử lý (Controller) của đối tượng đồ họa mà những thành phần còn lại vẫn giữ nguyên.

Kiến trúc MVC đã được ứng dụng để xây dựng rất nhiều framework và thư viện đồ họa khác nhau. Tiêu biểu là bộ thư viện đồ họa của ngôn ngữ lập trình hướng đối tượng SmallTalk (cũng do Xerox PARC nghiên cứu và phát triển vào thập niên 70 của thế kỷ 20). Các Swing Components của Java cũng được xây dựng dựa trên kiến trúc MVC. Ví dụ đi cùng với JButton là ButtonUI (thành phần View) và ButtonModel (thành phần Model). Ta hoàn toàn có thể viết MyButtonUI hoặc YourButtonUI để thay đổi giao diện của JButton theo ý mình (tương tự cho ButtonModel). Một điểm khá thú vị đối với Swing Components là nó cho phép ta chỉ thay đổi giao diện một phần nào đó của component. Ví dụ ta có thể thay đổi thể hiện của list item trong JList thông qua ListCellRenderer.

Ngay cả Microsoft Visual C++ (VC++) cũng ứng dụng MVC để xây dựng Document View Architecture. Bạn nào đã từng tạo một project MDI trong VC++ đều thấy rằng VC++ sẽ tạo ra các lớp CXXXDoc và CXXXView (XXX là tên project của chúng ta). CXXXDoc chính là thành phần Model và CXXXView là thành phần View của chương trình. Như vậy nếu theo đúng kiến trúc MVC thì tất cả những xử lý liên quan đến lưu trữ dữ liệu của chương trình phải được đặt ở CXXXDoc, còn những xử lý liên quan đến việc thể hiện phải được đặt ở CXXXView. Khi có sự thay đổi dữ liệu ở CXXXDoc, cần cập nhật lại hiển thị ở CXXXView, CXXXDoc sẽ gọi hàm UpdateAllView của nó để phát thông điệp thông báo cho tất cả các View gắn kết với nó. Tại CXXXView ta bắt sự kiện OnUpdate để cập nhật lại hiển thị của View. Hồi đó mỗi lần làm chương trình VC++, tchya đặt tất cả xử lý ở CXXXView, xong rồi ở CXXXDoc hay CMainFrame cần gọi cái gì đó của CXXXView thì cứ việc khai báo một con trỏ pView trỏ đến CXXXView. hì hì, giờ nghĩ lại thấy “bưởi” quá. Vì như vậy vô tình ta đã làm cho CXXXDoc và CMainFrame phụ thuộc (coupling) vào CXXXView, khi muốn thay đổi View thì rất khó khăn.

Khi cài đặt kiến trúc MVC ta cần lưu ý những điểm sau:

- Thành phần Model không cần thiết phải biết đến các View và Controller cụ thể gắn kết với nó. Khi có thay đổi, Model chỉ việc phát thông điệp cho những ai đăng ký với nó. Điều này có thể được thực hiện thông qua Observer Pattern.
- Nên áp dụng Facade Pattern để kết hợp Model, View, và Controller lại với nhau thành “3 trong 1” cho dễ quản lý và thao tác đối với người sử dụng.
- Kiến trúc MVC không phải là kiến trúc 3 tầng (3-Tiers Architecture). Mặc dù giữa 2 kiến trúc này có nhiều điểm tương đồng nhưng chúng nói về 2 khía cạnh khác nhau.

Mô hình MVC đơn giản


Mô hình MVC phức tạp hơn 1 tí

Nhậu có khổ không?

Ai bảo nhậu lai rai là khổ? Tôi mơ màng, men rượu bốc lên cao. Có những ngày say xỉn, té ở cầu ao, Vợ bắt được, chưa mắng câu nào đã khóc. Cô bé nhà bên nhìn tôi cười khúc khích: Chị giận anh rồi, tối….. sang ngủ với em…..

Đừng yêu dân IT

Đừng dại mà quen bọn ai ti (IT).
Chúng nó khô khan, lãng mạn gì?
Viết thư tán gái thì kinh dị.
Chúng viết bằng gì?
Ngôn ngữ C.
Đừng dại mà yêu bọn ai ti.
Chúng nó tài năng, mỗi tội kỳ.
Bạn gái chúng nó đòi đăng ký.
“Bẻ khoá được rồi đăng ký chi?”.
Đừng dại mà yêu bọn ai ti.
Chúng nó lăng nhăng đến lạ kỳ.
Gặp nhau anh í toàn năn nỉ.
Em mở mã nguồn cho anh đi.
Đừng dại mà yêu bọn ai ti.
Chúng nó yêu đương cái kiểu gì.
Gặp thì đòi cắm u ét bí (USB).
Lúc về nó bảo “Format đi”!.

Vô đối

Chỉ tay lên trời hận đời vô đối
Úp mặt xuống gối vô đối thật sao

Hận đời đen bạc
Hận kẻ bạc tình
Lấy máu xâm mình
Xâm lên bốn chữ
Hận người tôi yêu

Ăn xoài chớ chọn xoài chua
Chơi bạn đừng để bạn cua bồ mình.

Cà phê đắng bỏ đường thì ngọt
Tình cây đắng biết bỏ gì đây
Bỏ chanh, bỏ muối, bỏ đường
Bỏ gi thì bỏ chứ đừng bỏ anh.

Viết tên em trên bức trường trắng
Sọ lâu ngày mưa nắng nhạt phai
Viết tên em trên bức trường dài
Sọ lâu ngày bức tường kia sẽ đổ
Vậy đành khắc tên em trong trái tim này.

Trên trời triệu triệu vì sao
Xếp thành bốn chữ “vì sao yêu em”
Trần gian triệu triệu con người
Vì sao chỉ có một người mình yêu.

Con vua thì lại làm vua
Con sãi ở chùa thì quét lá đa”
Bao giờ con…giận người ta
Cửa chùa con sẽ đi ra quét hoài

Chỉ tay lên trời,hận đời Vô Đối
Úp mặt xuống gối,Vô Đối thật sao
Chổng mông lên cao,hỏi sao Vô Đối
Lẩn vào bóng tối……….VÔ ĐỐI là ta.

1 Đất nước

Trong 1 đất nước rất nhỏ có 1 thủ đô rất to.Trong thủ đô rất to có những con đường rất nhỏ Bên những con đường rất nhỏ có những ngôi biệt thự rất to Trong những ngôi biệt thự rất to có những cô vợ nhỏ’ Những cô vợ nhỏ là của các ông quan to Những ông quan to có cái cặp rất nhỏ Trong những cái cặp rất nhỏ có những dự án rất to Trong những dự án rất to thì hiệu quả lại rất nhỏ Hiệu quả rất nhỏ nhưng thất thoát thì rất to

12 câu nói phét hay nhất mọi thời đại

12 câu nói phét kinh điển nhất mọi thời đại 1. Internet: Chúng tôi hoàn toàn miễn phí. 2. Viễn thông: Chúng tôi bị lỗ vốn. 3. Cảnh sát: Chúng tôi vì nhân dân phục vụ 4. Công ty tham gia thị trường chứng khoán: Chúng tôi không làm giả các báo cáo. 5. Sếp: Tôi không bao giờ quên những cống hiến của anh. 6. Nhân viên: Mai tôi nghỉ việc, không làm nữa. 7. Tài xế xe khách: Nhà xe xuất phát đúng giờ. 8. Dân buôn: Bán lỗ vốn, đại hạ giá. 9. Ngôi sao điện ảnh: Chúng tôi chỉ làm bạn bè. 10. Chính khách: Tôi không nhận một đồng nào. 11. Con gái: Đây là lần đầu tiên của em. 12. Con trai: Ngoan, em yêu! Không đau tí nào đâu