Moô hình xử lý 3 layers

Có lẽ trong quá trình học và đi làm, bạn đã từng nghe qua chữ 3 lớp (3-layer), hoặc 3 tầng (3-tier), vậy nó là gì?

– Lớp trên cùng là Presentation, có nhiệm vụ tương tác với người dùng (actor), tất cả những gì liên quan đến hiển thị giao diện, dữ liệu, nhập xuất… sẽ nằm ở đây. Các thao tác xác thực kiểu dữ liệu (email, phone…) cũng ở đây. Trong lớp này bạn không cần quan tâm đến cấu trúc sơ sở dữ liệu, hay nói chính xác hơn, bạn sẽ không thao tác trực tiếp với CSDL tại lớp Presentation.

– Lớp chính giữa là Business Logic layer (BL), lớp này sẽ nắm toàn bộ logic của chương trình, các quy tắc xử lý, ràng buộc… đều phải được kiểm tra tại đây.

– Lớp dưới cùng là Data layer, các thao tác lưu trữ, cập nhật… sẽ được xử lý tại đây.

– Presentation: Chính là các trang JSP, PHP… của bạn, khi viết các trang web, bạn chỉ cần lấy dữ liệu từ Business Logic, và hiển thị ra màn hình. Bạn không cần quan tâm dữ liệu đó từ đâu ra, chỉ cần biết có dữ liệu và hiển thị – hết. Cũng vậy, khi người dùng submit dữ liệu, lớp Presentation cũng chỉ áp dụng các phép kiểm tra cơ bản như: người dùng đã nhập email hợp lệ hay chưa, hay số lượng hàng trong giỏ có hợp lệ hay không. Khi áp dụng MVC (*) vào mô hình 3 lớp, toàn bộ phần MVC này đều nằm trong lớp Presentation (chứ không phải chỉ có View đại diện cho Presentation). (**)

– Business Logic (BL): Các quy tắc xử lý và xác thực dữ liệu sẽ nằm tại đây (***). Khi bạn nhấn nút “Đặt hàng”, những gì Presentation gửi xuống là thông tin người nhận, thông tin thanh toán và nội dung giỏ hàng. Sau khi kiểm tra xem dữ liệu có hợp lệ hay không, BL sẽ làm hàng loạt thao tác bên trong: kiểm tra kho hàng tạo một đơn hàng trong CSDL (thông qua lớp Database Access), cập nhật lại trạng thái sản phẩm trong kho hàng, gửi thông báo cho người bán, gửi thông tin giao hàng cho bộ phận đóng gói và giao nhận, thông báo cho khách hàng về đơn hàng mới… Lớp Presentation sẽ không biết gì về các thao tác bên trong BL, mà chỉ nhận về kết quả thành công hay không, rồi thông báo cho khách hàng.

– Data: nhận yêu cầu từ BL để thực hiện các nhiệm vụ: tạo một bản ghi đơn hàng mới, cập nhật trạng thái sản phẩm trong kho, cập nhật lại thông tin khách hàng (thống kê, điểm tích lũy…).

– Đơn giản, dễ hiểu.

– Có thể chuyển đổi dễ dàng giữa các mô hình cloud và on-premise (tức cài đặt trên các máy tính riêng).

– Dễ dàng chuyển đổi từ các kiến trúc truyền thống.

– Cho phép sử dụng xen kẽ giữa các nền tảng khác nhau (Linux, Windows…)

– Việc tách ứng dụng ra làm các tầng khác nhau đôi khi khá khó khăn, nhất là các ứng dụng lớn.

– Chia hệ thống ra chạy trên nhiều máy tính sẽ dẫn đến phát sinh độ trễ do giao tiếp qua mạng.

– Việc quản lý bảo mật cũng như quản trị nhiều máy chủ sẽ khó khăn hơn.

– Tránh việc tạo ra một tầng Business Logic chỉ để gọi lại các phương thức CRUD của Database.

– Có thể dùng cache để giảm các lời gọi đến tầng bên dưới.- Các tầng nên được thiết kế stateless, tức không lưu trữ lại trạng thái qua các lần gọi. Stateless cho phép bạn gọi đến bất kỳ component nào, chạy trên bất kỳ máy nào mà không cần quan tâm đến trạng thái hiện tại của component đó, nhờ vậy việc scale out sẽ dễ dàng hơn. Ở tầng Presentation, nếu dùng Session ta có thể sử dụng các cơ sở dữ liệu chia sẻ (memcache, SQL Server…) để lưu trữ session data, nhờ đó request từ người dùng có thể được phân phối đến bất kỳ máy chủ web nào.

– Tận dụng các nền tảng và công nghệ sẵn có: EJB trong J2EE và COM+ trên Windows là 2 công nghệ được sinh ra để hỗ trợ các ứng dụng n-tier. Tuy nhiên, hiện tại triển khai các component thông qua web là một ý tưởng không tồi – nếu không nói là rất tốt và đã trở nên phổ biến.

– Tránh hoàn toàn việc gọi đến Data tier từ một tầng khác phía trên Business Logic tier.

– Sử dụng các load balancer ở mỗi tầng giúp việc scale out dễ dàng hơn rất nhiều.- Có thể sử dụng các cơ chế gửi thông điệp không đồng bộ (asynchronous messaging: MSMQ, RabbitMQ, SNS, SQS…) để giảm mức độ phụ thuộc giữa các tầng.

– Mỗi tầng nên được đặt trong một subnet riêng, giúp tăng cường bảo mật.

– Khi sử dụng một cơ sở dữ liệu có sẵn, một cách tự nhiên ứng dụng của chúng ta đã ở dạng 2-tier. Trong các ứng dụng thường có một số lớp đảm nhiệm việc truy vấn dữ liệu, ta thường gọi là DAL (data access layer), layer này giúp truy vấn dữ liệu dễ dàng hơn, nhưng không phải là một tier trong n-tier (vì vậy ta chỉ có data access layer chứ không có data access tier).

– (*) MVC chỉ được coi là một design pattern trong tầng Presentation.

– (**) Nếu bạn truy cập CSDL ngay trong controller, như vậy ứng dụng của bạn là 2-tier chứ không phải 3-tier.

– (***) Việc kiểm tra dữ liệu tại Presentation layer giúp giảm bớt lời gọi (thừa) đến BL, tuy nhiên trong BL vẫn phải có các thao tác kiểm tra để đảm bảo tính đúng đắn của dữ liệu.