Bạn sẽ nghe nói đến thuật ngữ kiến trúc đa tầng/nhiều lớp, mỗi lớp sẽ thực hiện một chức năng nào đó, trong đó mô hình 3 lớp là phổ biến nhất. 3 lớp này là: Presentation, Business Logic, và Data Access. Các lớp này sẽ giao tiếp với nhau thông qua các dịch vụ(services) mà mỗi lớp cung cấp để tạo nên ứng dụng, lớp này cũng không cần biết bên trong lớp kia làm gì mà chỉ cần biết lớp kia cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi.

Presentation Layer (PL)

Lớp này làm nhiệm vụ giao tiếp với người dùng đầu cuối (đơn giản là người sử dụng phần mềm) để thu thập dữ liệu và hiển thị kết quả hoặc dữ liệu thông qua các thành phần giao diện người sử dụng như Jtable trong Swing… Lớp này sử dụng các dịch vụ do lớp Business Logic Layer cung cấp.

Trong lớp này có 2 thành phần chính là User Interface Components và User Interface Process Components.

UI Components là những phần tử chịu trách nhiệm thu thập và hiển thị thông tin cho người dùng cuối.

UI Process Components: là thành phần chịu trách nhiệm quản lý các qui trình chuyển đổi giữa các UI Components. Ví dụ chịu trách nhiệm quản lý các màn hình nhập dữ liệu trong một loạt các thao tác định trước như các bước trong một Wizard…

Business Logic Layer (BLL)

Lớp này thực hiện các nghiệp vụ chính của hệ thống, sử dụng các dịch vụ do lớp Data Access cung cấp, và cung cấp các dịch vụ cho lớp Presentation. Lớp này cũng có thể sử dụng các dịch vụ của các nhà cung cấp thứ 3 (3rd parties) để thực hiện công việc của mình(ví dụ như sử dụng dịch vụ của các cổng thanh tóan trực tuyến như VeriSign, Paypal…).

Trong lớp này có các thành phần chính là Business Components, Business Entities và Service Interface.

Service Interface là giao diện lập trình mà lớp này cung cấp cho lớp Presentation sử dụng. Lớp Presentation chỉ cần biết các dịch vụ thông qua giao diện này mà không cần phải quan tâm đến bên trong lớp này được hiện thực như thế nào.

Business Entities là những thực thể mô tả những đối tượng thông tin mà hệ thống xử lý. Trong ứng dụng chúng ta các đối tượng này là các chuyên mục(Category) và bản tin(News) làm nhiệm vụ cung cấp các dịch vụ quản lý chuyên mục và các bản tin (thêm, xóa, sửa, xem chi tiết, lấy danh sách…). Các business entities này cũng được dùng để trao đổi thông tin giữa lớp Presentation và lớp Data Access.

Business Components là những thành phần chính thực hiện các dịch vụ mà Service Interface cung cấp, chịu trách nhiệm kiểm tra các ràng buộc logic(constraints), các qui tắc nghiệp vụ(business rules), sử dụng các dịch vụ bên ngoài khác để thực hiện các yêu cầu của ứng dụng.

Data Access Layer (DAL)

Lớp này thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của ứng dụng. Thường lớp này sẽ sử dụng các dịch vụ của các hệ quản trị cơ sở dữ liệu như SQL Server, Oracle,… để thực hiện nhiệm vụ của mình. Trong lớp này có các thành phần chính là Data Access Logic, Data Sources, Servive Agents).

Data Access Logic components (DALC) là thành phần chính chịu trách nhiệm lưu trữ vào và truy xuất dữ liệu từ các nguồn dữ liệu (JDBC trong Java)

Data Sources như RDMBS, XML, File systems…

Service Agents là những thành phần trợ giúp việc truy xuất các dịch vụ bên ngòai một cách dễ dàng và đơn giản như truy xuất các dịch vụ nội tại.

Việc tách lớp này có lợi khi sau này, bạn muốn thay đổi database từ MySql sang MSSql hoặc Oracle, bạn chỉ việc thay đổi lớp DAL mà không làm ảnh hưởng các lớp khác.

Theo hình vẽ, quy trình sẽ đi theo ngược chiều kim đồng hồ theo các bước sau:

1. Presentation layer yêu cầu BLL lấy dùm vài object, ví dụ thông tin 1 person.

2. BLL có thể thực hiện các kiểm tra (validation) (ví dụ, người dùng hiện tại có được phép gọi hàm này hay không?) và chuyển yêu cầu đến DAL.

3. DAL kết nối với database và yêu cầu lấy về record.

4. Khi tìm thấy record, database sẽ trả nó về DAL.

5. DAL gói (wrap/ map) database data vào một custom object (ở ví dụ này là object person) và trả nó về BLL.

6. Cuối cùng, BLL sẽ trả về object cho Presentation layer, và từ đó hiển thị lên web page. MÔ HÌNH ỨNG DỤNG Client/Server 3 lớp(business logic 3-Tier)

Nhược điểm của mô hình 2 lớp:

- Tính toán tập trung ở phía Client (Fat client – Thin Server):

+ Khó nâng cấp vì phải cập nhật lại phần mềm ở toàn bộ các client.

+ Do mọi thao tác trên CSDL đều thông qua mạng giữa client và server nên tốc độ của hệ thống sẽ chậm đi.

- Tính toán tập trung ở phía Server (Fat Server – Thin Client):

+ Việc sửa đổi hoặc mở rộng sever trở nên không khả thi và tốn kém vì mã lệnh bị trộn giữa nghiệp vụ và cơ sở dữ liệu.

+ Server dễ bị quá tải do phải đáp ứng quá nhiều nhiệm vụ (cả bussiness logic và database). Nếu chia ra nhiều server thì dữ liệu bị phân tán.

Mô hình 3 lớp:

Mô hình này bổ sung một server tương tác giữa Client và Database Server gọi là Application Server.

-Client:

Là các web Browser đã có sẵn (như Internet Explorer, Firefox, Opera ...) và chỉ hiểu ngôn ngữ HTML (hiện các Browser mới hiểu thêm được cả XHTML, XML). Một Browser có thể dùng để truy cập nhiều trang web và không thể thực hiện chức năng xử lý tính toán nào.

-Application Server hay Web Server:

Web Server (máy phục vụ Web): máy tính mà trên đó cài đặt phần mềm phục vụ Web, đôi khi người ta cũng gọi chính phần mềm đó là Web Server.

Tất cả các Web Server đều hiểu và chạy được các file *.htm và *.html, tuy nhiên mỗi Web Server lại phục vụ một số kiểu file chuyên biệt chẳng hạn như IIS của Microsoft dành cho *.asp và *.aspx, Apache dành cho *.php, Sun Java System Web Server của SUN dành cho *.jsp ...

-Thực hiện các yêu cầu mà Web Browser gởi tới.

- Kết quả thực hiện của các đối tượng chạy trên Web Server phải ở dạng HTML, XHTML, XML.

-Database Server (máy chủ cơ sở dữ liệu):

Máy tính mà trên đó có cài đặt Hệ quản trị cơ sở dữ liệu quan hệ (RDBMS). Chúng ta có một số RDBMS chẳng hạn như: SQL Server, MySQL, Oracle ... Thực hiện mọi thao tác trên cơ sở dữ liệu do Web Server yêu cầu.

Ưu điểm của mô hình 3 lớp:

- Hỗ trợ nhiều người dùng hơn.

- Loại bỏ hoàn toàn sự phụ thuộc của Client.

- Business logic được chứa trong lớp Application Server nên có những ưu điểm:

+ Khả năng bảo mật và an toàn hệ thống tốt hơn: Lớp GUI không hề chứa mã lệnh thao tác trực tiếp trên CSDL, mà chỉ chứa các yêu cầu phục vụ đến lớp thứ 2. Vì vậy nếu nhà phát triển phân tích và xây dựng các

phương thức phục vụ ở lớp business logic kỹ lưỡng và an toàn thì hệ thống sẽ đạt độ bảo mật rất cao.

+ Dễ mở rộng: bằng cách dùng nhiều Application Server (không dùng nhiều Database Server vì khi đó dữ liệu sẽ bị phân tán).

- Dễ quản lý: việc nâng cấp, sửa đổi có thể thực hiện ở tầng vật lý tương ứng.

Nhược điểm của mô hình 3 lớp:

- Tốn nhiều công sức cài đặt (nhiều server) hơn.

Lưu ý 3-layer và 3-tier là hai khai niệm khác nhau, nói đến layer là nói đến cách tổ chức ứng dụng (vd các package trong java), còn tier là ám chỉ sự tách bạch về mặt vật lý ( client - app server - data server).

3 tầng cũng chưa phải là nhiều. Hiện tại thì người ta còn chia nhỏ BLL ra thành nhiều tầng nữa. Do đó khái niệm đúng là ta dùng n-tier trong web application

So sanh' với MVC

Phương pháp thiết kế MVC bắt nguồn từ việc phát triển giao diện người dùng trong ngôn ngữ lập trình Smalltalk, đây là một trong những phương pháp thiết kế thành công nhất trong các phương pháp thiết kế hướng đối tượng. Hiện nay, MVC được dùng rộng rãi trong nhiều hệ thống phần mềm.[/QUOTE]

- Model: Model được giao nhiệm vụ cung cấp dữ liệu cho cơ sở dữ liệu và lưu dữ liệu vào các kho chứa dữ liệu. Tất cả các nghiệp vụ logic được thực thi ở Model. Dữ liệu vào từ người dùng sẽ thông qua View đến Controller và được kiểm tra ở Model trước khi lưu vào cơ sở dữ liệu. Việc truy xuất, xác nhận, và lưu dữ liệu là một phần của Model. Do có 2 vai trò tương đối tách biệt cho nên một Model thường được tách thành các lớp có các domain xử lý khác biệt:

+ Business logic thường là xử lý rule hay policy của nghiệp vụ cũng như business workflows.

+ Domain data: Cung cấp/lưu trữ dữ liệu và việc chuyển đổi dữ liệu thành các dạng khác nhau theo yêu cầu

- View: View hiển thị các thông tin cho người dùng của ứng dụng và được giao nhiệm vụ cho việc nhận các dữ liệu vào từ người dùng, gửi đi các yêu cầu đến controller, sau đó là nhận lại các phản hồi từ controller và hiển kết quả cho người dùng. Các trang HTML, JSP, các thư viện thẻ và các file nguồn là một phần của thành phần View.

Trong các web framework, nó gồm 2 phần chính:

+ Template file định nghĩa cấu trúc và cách thức trình bày dữ liệu cho user. Ví dụ như layout, color, windows …

+ Logic xử lý cách áp dụng dữ liệu vào cấu trúc trình bày. Logic này có thể bao gồm việc kiểm tra định dạng dữ liệu, chuyển đổi định dạng dữ liệu sang một sạng dữ liệu trung gian, lựa chọn một cấu trúc hiện thị phù hợp.

- Controller: controller đảm nhiệm việc cập nhật bộ phận hiển thị (View) khi cần thiết. Bộ điều khiển này nhận dữ liệu nhập từ người dùng, truy xuất các thông tin cần thiết từ mô hình trong (Model), và cập nhật thích hợp phần hiển thị (View). Giao diện với người sử dụng phần mềm được thiết lập nhờ sự tương tác qua lại giữa View và

Controller: hai bộ phận này chính là phần trình bày bên ngoài của đối tượng biểu diễn bên trong.

Martin Fowler chia MVC thành hai phiên bản là Passive View và Supervising Controller.

Trong mẫu Passive View, thành phần View được loại bỏ hoàn toàn các xử lý logic và tương tác đến Model. Thay vì vậy, nó chuyển giao các xử lý cho Controller đảm trách. Controller đảm nhận tương tác đến Model và cập nhật View khi có thay đổi từ Model. Controller là thành phần trung gian liên lạc giữa View và Model.

Trong mẫu Supervising Controller, View đầu tiên bắt lấy các sự kiện và sau đó chuyển giao cho Controller xử lý. Để cập nhật thay đổi từ Model, View dùng data-binding và Observer Pattern cho các xử lý đơn giản còn đối với các xử lý phức tạp sẽ nhờ đến Controller

So sánh MVC và 3-layer/tier:

Giống nhau:

- Cả hai đều để tách rời programming core/business logic ra khỏi những phụ thuộc về tài nguyên và môi trường.

- Trong một ứng dụng nhỏ, MVC thể hiện thế nào? Presentation thể hiện giống như chức năng của View và Controller. Business và Database thể hiện giống như chức năng của Model. Như thế nhìn ở góc độ này, thì MVC tương đương với 3-layer (tất nhiên có chồng chéo như hình vẽ)

Khác nhau:

Trong 3-layers, quá trình đi theo chiều dọc, bắt đầu từ Presentation, sang BL, rồi tới Data, và từ Data, chạy ngược lại BL rồi quay ra lại Presentation.

Bài viết sau đây giới thiệu tổng quan về phương pháp thiết kế MVC, và minh họa cách sử dụng MVC trong thiết kế hướng đối tượng bằng việc xây dựng chương trình Java Web Mail, sử dụng JSP, Servlet và Java Mail API:

Java là một ngôn ngữ lập trình hướng đối tượng thuần túy nên việc áp dụng MVC vào các phần mềm viết bằng Java rất dễ dàng và hiển nhiên. Có hai hình mẫu chính của phương pháp thiết kế MVC trong Java là MVC Model 1 và MVC Model 2.

Dưới đây là sơ đồ của MVC model 1:

Trong MVC model 1, các trang JSP đóng vai trò Hiển thị (View) và Điều khiển (Controller). Có thể có nhiều trang JSP khác nhau đóng các vai trò khác nhau.

* Khi người sử dụng dùng các nút bấm, menu hoặc link … trên trình duyệt Web (Web browser) để thực hiện một thao tác, một lệnh (có thể kèm theo các tham số) được gửi tới một trang JSP tương ứng.

* Trang JSP này sẽ khởi tạo một hoặc nhiều Java Bean (nếu cần thiết), truyền các lệnh cần thi hành tới Java Bean. Chú ý rằng đây là các Java Bean thông thường, chứ không phải Enterprise Java Bean (EJB)

* Sau khi Java Bean thực hiện xong việc truy xuất hoặc cập nhật dữ liệu, trang JSP ban đầu có thể hiển thị dữ liệu lấy từ Bean (JSP ban đầu đóng luôn vai trò View), hoặc chọn một trang JSP khác để hiện dữ liệu từ Bean (JSP ban đầu đóng luôn vai trò Controller). Trong một thiết kế tốt, để bảo đảm việc tách rời phần trình bày và logic của chương trình, trang JSP nhận request chỉ đóng vai trò Điều khiển (Controller).

MVC model 1 có một nhược điểm là phần logic điều khiển được viết trong trang JSP, như vậy phần chương trình Java phức tạp dùng để điều khiển sẽ bị lẫn vào trong mã HTML dùng để trình bày. Độ phức tạp của chương trình càng cao, thì trang JSP càng khó bảo trì. Hơn nữa trong các dự án phần mềm phức tạp, thì phẩn hiển thị của trang JSP thường được làm bởi người thiết kế Web, giỏi về HTML và đồ họa, còn phần chương trình Java được viết bởi lập trình viên chuyên về lập trình. Trong các dự án phức tạp, dùng JSP làm phần điều khiển sẽ làm lẫn lộn việc phân chia ranh giới trách nhiệm giữa nhóm thiết kế đồ họa và nhóm lập trình, đôi khi dẫn đến việc bảo trì và phát triển trở nên rất khó khăn, gần như không thể làm được.

Để khắc phục nhược điểm này, MVC model 2 ra đời. Dưới đây là sơ đồ của MVC model 2:

Trong MVC model 2, một hoặc nhiều servlet (thường là một) đóng vai trò Điều khiển, các Java Bean đóng vai trò Mô hình và các trang JSP đóng vai trò hiển thị.

Trong model 2, các logic phức tạp của chương trình được viết hoàn toàn trong các servlet, là các chương trình Java. Phần hiển thị chỉ gồm các trang JSP với một vài mã đơn giản để lấy dữ liệu có sẵn, không có logic phức tạp, vì thế hoàn toàn có thể được tạo ra bằng những người thiết kế Web.

Các yêu cầu của người dùng được gửi từ trình duyệt Web tới servlet. Servlet sẽ khởi tạo Java Bean (nếu cần thiết), ra lệnh thu thập, cập nhật thông tin. Khi Java Bean hoàn thành công việc, servlet sẽ chọn trang JSP thích hợp để hiện thông tin trong Java Bean cho người dùng.

Đây là một cách sử dụng MVC rất hiệu quả trong Java. Tất nhiên, sử dụng MVC model 2 một cách hoàn toàn cứng nhắc, phần “Điều khiển” chỉ dùng servlet, phần “Hiển thị” chỉ dùng JSP sẽ dẫn đến một vài trường hợp kém hiệu quả, nhất là khi các yêu cầu từ trình duyệt web chỉ đòi hỏi việc hiển thị thông tin.

Ví dụ: một trang Web đang hiện các mail trong mail box từ mail thứ 20 đến mail thứ 40. Danh sách các mail này đã có sẵn phần Mô hình khi người dùng login và phần Điều khiển ra lệnh cho phần Mô hình lấy danh sách các mail có trong mail box trong POP server. Từ trang Web này, người dùng phát ra một yêu cầu “Next” để xem tiếp danh sách các mail từ mail thứ 40 đến mail thứ 60. Đây đơn thuần chỉ là đòi hỏi thông tin hiển thị, do đó, nếu gửi qua servlet Điều khiển , servlet sẽ không làm gì cả, mà chỉ gửi yêu cầu hiển thị tới trang JSP hiển thị danh sách mail. Trong trường hợp này, gửi thẳng yêu cầu hiển thị từ trình duyệt Web tới trang JSP sẽ hiệu quả hơn.

Sơ đồ cho cách áp dụng MVC nói trên như sau:

Trong cách áp dụng MVC này, các yêu cầu có liên quan đến logic chương trình hoặc truy cập dữ liệu sẽ được gửi tới servlet controller, còn các yêu cầu chỉ liên quan tới hiển thị sẽ được gửi tới JSP controller.

Đây chính là cách tôi chọn để cài đặt chương trình Java Web Mail.

Chương trình Java Web Mail bao gồm các thành phần sau :

* Một servlet controller MailUtilServlet, dùng để nhận các yêu cầu: login, logout, gửi mail, hiện attachment. Những yêu cầu này sẽ được xử lý về mặt logic rồi gửi tới Java Bean để thực sự làm công việc truy cập mail server. Sau khi Java Bean thực hiện việc truy cập dữi liệu xong, MailUtilServlet sẽ chọn trang JSP thích hợp để hiện dữ liệu.

* Một Java Bean MailUserBean dùng để truy cập mail server, lấy danh sách và mội dung mail trong mail box, xóa mail trong server.

* Trang JSP index.jsp đóng vai trò JSP controller, dùng để nhận các yêu cầu: hiện danh sách các mail trong mail box, hiện nội dung của một mail được chọn trong danh sách, hiện trang soạn thảo mail để người dùng soạn thảo và gửi mail. Những thông tin cần để hiển thị đã có sẵn trong MailUserBean, vì MailUserBean đã lấy những thông tin này khi nhận được yêu cầu login từ MailUtilServlet. Vì thế, những loại yêu cầu này thuộc về loại yêu cầu hiển thị, không có logic phức tạp, nên không cần phải gửi qua MailUtilServlet.

* Một tập hợp các trang JSP:

o menu.jsp dùng để hiện menu lệnh bao gồm Log in, Inbox, Compose và Exit

o first.jsp là trang để nhập username, password, mailserver cho việc login

o messageheaders.jsp là trang để hiện danh sách các mail có trong mail box để người dùng chọn xem và xóa mail trong mail box.

o messagecontent.jsp là trang để hiện nội dung của một mail đã được chọn từ danh sách.

o compose.jsp là trang để soạn thảo mail cần gửi.

o status.jsp là trang dùng để báo về lỗi khi log in, log out không thành công, và thông báo về kết quả gửi mail thành công hay không.

o errordetails.jsp là trang dùng để cung cấp thông tin chi tiết mỗi khi có lỗi log in, log out, gửi mail không thành công. Thông tin trong trang này bao gồm cả Stack Trace của exception khi sinh ra lỗi, chủ yếu dành cho lập trình viên dùng để xem chi tiết về vấn đề đã xảy ra.

o logout.jsp là trang hiện ra khi người dùng login ra khỏi hệ thống mail.

Một vài trang JSP và text file khác dùng để trang trí.

o Một CSS (Cascade Style Sheet) tên là styleSheet.txt, dùng để định dạng về font và màu sắc cho tất cả các file JSP.

Trong hệ thống này, không có database sever. MailUserBean lấy và cập nhật dữ liệu từ POP mail server, gửi mail từ SMTP server, sử dụng Java Mail API.

Chương trình gồm có các chức năng sau:

- Sử dụng HTTP để đọc và gửi mail từ bất kỳ một mail server nào dùng POP3 Protocol trên Internet hoặc trong Intranet.

- Có thể truy cập mail qua bất kỳ một proxy server nào có chức năng HTTP proxy. Chức năng này rất có ích khi người dùng kết nối vào Internet từ một mạng Intranet phía sau một firewall, và firewall này ngăn chặn các máy tính trong Intranet truy cập POP server bên ngoài, trong khi đó, người sử dụng muốn gửi và nhận mail từ một POP server trên Internet.

- Sử dụng khả năng xử lý các loại dữ liệu (content handling) của trình duyệt Web để hiện Attachment.