MÔ HÌNH 3 LỚP


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ì?

ℹ️ Mô hình 3 lớp là một dạng kiến trúc ứng dụng, trong đó các phần của chương trình được gom vào 3 lớp khác nhau (xem hình minh họa). Thực chất mô hình 3-layer chỉ là một trường hợp đặc biệt của mô hình tổng quát hơn là n-layer, với số lớp có thể từ 2 đến n, các lớp này sẽ nằm lên nhau, và mỗi lớp sẽ chỉ gọi và nhận kết quả xử lý từ lớp ngay bên dưới nó.

👉Trong 3-layer, người ta sẽ chia ứng dụng làm 3 lớp khác nhau:

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

👉Lấy ví dụ một trang web bán hàng, ta sẽ chia ứng dụng ra làm 3 lớp:

– 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…).

👉 Việc chia ứng dụng ra làm nhiều lớp giúp các phần của chương trình tách bạch hơn, việc kiểm lỗi hoặc triển khai cũng dễ dàng hơn.

ℹ️ Scale up và scale out:Khi viết các ứng dụng lớn và có nhu cầu nâng cấp khả năng chịu tải, ta sẽ có hai lựa chọn là:- Scale up: nâng cấp máy tính đang chạy, gắn thêm RAM, thêm CPU, đĩa cứng…- Scale out: thêm một máy tính vào mạng và chia sẻ tải cho máy tính mới đó.

ℹ️ 3-layer VS 3-tier:Khi nói đến lớp (layer) ta nói đến việc phân chia một cách logic, và thường các lớp sẽ nằm trong các “gói” riêng (các file DLL, Jar…), việc giao tiếp giữa các lớp vẫn là lời gọi hàm thông thường, các lớp vẫn chạy trong cùng một memory space. Do vậy khi triển khai, chúng vẫn phải chạy trên cùng một máy tính, muốn nâng cấp ta chỉ có một lựa chọn là scale up.Để hỗ trợ khả năng scale out, ta sẽ chia ứng dụng ra thành nhiều tầng (tier), mỗi tầng có thể chứa một hoặc nhiều layer. Các tầng này sẽ tương tác với nhau thông qua các kỹ thuật gọi hàm từ xa. Nhờ vậy khi cần nâng tải, ta chỉ cần thêm máy tính, cài đặt tier đang thiếu tải lên đó và hướng dẫn các tầng bên trên nó sử dụng máy tính mới.

👉 Ưu điểm của n-tier:

– Đơ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…)

👉 Khó khăn:

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

👉 Best practices:

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

ℹ️ Ghi chú:

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s