Muốn hiểu tại sao người ta chia một phần mềm có lưu trữ data ra thành 3 lớp (3-tier), thì phải nhìn từ lịch sử lập trình, nghĩa là tại sao người ta cần chia một phần mềm ra thành nhiều phần khác nhau. Rồi những phần đó tại sao lại được xếp nhóm vào 3 lớp chính là Presentation, Business logics và Data.
Lý do về việc tại sao phải chia phần mềm thành nhiều phần để viết, ở đây các bác của em toàn là cao thủ lập trình, chắc em không cần phải nhắc lại. Thế rồi giải thích tại sao lại chia phần mềm thành ba lớp chính là Presentation, Business logics và Data, thì cũng đơn giản như giải thích tại sao bánh xe hình tròn, tại sao TCP/IP có 4 lớp và OSI có 7 lớp.
Ngắn gọn là sau nhiều chục năm thử và sai, kinh nghiệm cho người ta thấy rằng chia phần mềm thành 3 tier chính như thế có tác dụng tốt nhất cho những việc như sau đây:
– Phát triển phần mềm: Có tính chuyên nghiệp hóa, có thể chia cho nhiều nhóm được đào tạo nhiều kỹ năng khác nhau, từ thiết kế mỹ thuật cho đến lập trình đến tổ chức database.
– Bảo trì: Với các lớp được phân chia theo như đã nói, thì các thành phần của một hệ thống dễ được thay đổi, nhưng sự thay đổi có thể được cô lập trong từng lớp, hoặc chỉ ảnh hưởng đến lớp ngay gần kề của nó, chứ không phát tán náo loạn trong cả chương trình.
– Mở rộng: Với các lớp được chia theo 3-tier như đã nói, việc thêm chức năng vào cho từng lớp sẽ dễ dàng hơn là phân chia theo cách khác.
Còn tại sao, các bác cứ thử chia theo cách khác, ví dụ không thành Presentation, Business và Data, mà thành cái quái gì đấy, rồi mở rộng, thay đổi các thành phần thì chắc là khó hơn.
He..he..mà cũng chưa chắc, vì chân lý là cái lý có chân, tức là nó chạy đi chạy lại theo thời gian.
Sau khi đã chia thành 3 tier chính như đã nói, trong mỗi tier người ta có thể chia thành nhiều layer. Nói chung là trong software, người ta dung từ layer và tier interchangeable, tiếng Việt lại toàn dịch là lớp. Nói là nhiều tier hay nhiều layer, nói chung không sai. Nhưng nhóm các layer cùng chức năng tương tự lại, thì bao giờ cũng gồm ba nhóm chính là Presentation – Business logics – Data.
Còn MVC Design pattern là một design pattern dành riêng cho Presentation layer, chứ không phải là cách chia toản bộ một application ra thành 3 tier là Model – View – Controller.
Trong đó, View là các display objects, ví dụ như window, frame, dialog, panel hoặc Web page (HTML page, HTML template, XML template, JSP, ASP, ASPX, PHP template, Ruby template …), chỉ dùng để hiển thị thông tin, các visual objects để tương tác với người dùng …
Model là các in-memory objects, chứa thông tin về các business objects mà hệ thống chương trình sử dụng.
Controller là phần xử lý logic. Logic này bao gồm việc thu nhận yêu cầu từ người dùng, xử lý, tính toán theo yêu cầu, tìm kiếm, khởi tạo các in-memory objects (các model), xử lý các models, và lựa chọn view cần thiết, gửi thông tin đến view, và gửi view vào mặt user.
Em của các bác có một bài viết về implementation cho MVC Design Pattern trong Java ở đây:
http://www.hanoian.com/index.php?opt…38&Itemi d=44
Trong đấy em có nói qua về MVC model 1, MVC model 2 trong J2EE kinh điển, và có đề nghị một giải pháp về mixed MVC, có giải thích lý do, và cung cấp code.
Các bác thích thì vào đọc.
MVC chỉ là sự chia nhỏ các thành phần có tương tác với user, nghĩa là các thành phần trong Presentation layer..
Các Model có thể được tạo ra từ các nguồn khác nhau.
– Các thông tin do user gõ vào. Ví dụ như các bác viết một chương trình giải phương trình bậc nhất ax + b = 0.
Như vậy các bác có thể tạo ra một trang web có 2 cái text box, một cái nhập a, một cái nhập b, và một nút bấm “Tính nghiệm”, hoặc một cái stand-alone GUI bằng VB, bằng VC ++ hoặc bằng whateverthehell các bác thích, có chỗ để nhập nghiệm. Đấy gọi là view.
Còn cái mà các bác định nghĩa là “float a, b, x” hoặc “Dim a, b, x As con khỉ gì đấy” thì chính là model, in-memory object để lưu data.
Còn controller có thể là một class riêng biệt để tính nghiệm. Method của class này được gọi trong phần xử lý event hay Submit của cái nút bấm. Hoặc nhiều khi các bác không thích, thì viết luôn phần tính nghiệm trong cái method xử lý event của cái nút bấm.
Như vậy, trong trường hợp này, phần mềm không có Data tier.
– Có trường hợp thì model là in-memory copies của objects trong database, hoặc của e-mail trong mail server, hoặc của objects trong LDAP repository, hoặc trong file trên đĩa cứng …
Trong trường hợp các ứng dụng đơn giản nhất, thì phần truy cập data để khởi tạo in-memory objects sẽ được viết luôn trong controller.
Như thế, ranh giới giữa Presentation layer và Business logic trở nên mờ nhạt. Điều này không hoàn toàn có nghĩa là xấu, nếu như ứng dụng của các bác đủ đơn giản.
Nhưng khi logic để access data trở nên phức tạp, thì việc truy cập data sẽ được tách thành một (hoặc một nhóm ) component riêng, bên ngoài Controller. Như thế sẽ hình thành một layer gọi là Data access layer ở trong Business tier.
Ngoài ra, việc xử lý, tính toán thuần túy trên models, không liên quan gì đến logic của việc trình bày thông tin trên màn hình, cũng có thể được tách riêng ra, thành Business computational layer, nằm trong Business tier.
Như vậy thì trong Controller chỉ còn logic liên quan đến presentation, ví dụ như định dạng layout, chọn view, định dạng thông tin của object được in ra…
Rồi những vấn đề như login (Authentication) và access control (Authorization) cùng với các dịch vụ về Data Encryption và Data Decryption cũng có thể được tách riêng ra thành security layer.
Còn nhiều thứ tương tự.
Như vậy chúng ta có thể thấy là chia phần mềm thành các tier như đã nói, thì về căn bản, các tier có thể được xếp vào 3 nhóm chính là Presentation, Business logics và Data.
Trong từng tier, có thể chia thành nhiều layer khác nhau. Như vậy mới có cái gọi là kiến trúc n-tier, multi-tier hay là n-layer, multi-layer …
Nhưng chia phần mềm theo 3-tier như đã trình bày, chỉ là một cách chia, cách này gọi là horizontal slice. Cho đến nay, số đông trong ngành kiến trúc phần mềm vẫn đồng ý đây là cách chia tốt nhất.
Tuy nhiên, như em đã nói đâu đó ở trên, chân lý là cái lý có chân. Vì thế hôm qua thầy giáo các bác, hoặc sách của Tây rậm râu và Tây trán hói nói là 3-tier là tốt nhất, hôm nay rất có thể cái lý nó không còn ở chỗ đấy nữa.
Comes in the picture: Vertical slice and SOA
Khi khác em lại viết tiếp về vertical slice và SOA.
Rồi còn chuyện MVC bị dùng sai trong nhiều software project ở Mỹ như thế nào, nhiều khi cũng rất nực cười và thê thảm.
Chau Hong Linh (http://connekgroup.net/forum/showthread.php?t=1615)
fly2universe's Weblog 