Kiến trúc "Củ hành" (Onino Architecture)

Trong bài trước cùng chuỗi series, khi chỉ có sự phân tách logic trong ứng dụng của bạn, chúng ta có thể gọi nó là các Layers hoặc N Layers. Trong trường hợp có cả sự phân tách vật lý và logic trong Project, nó thường được gọi là ứng dụng N-tiers trong đó N là số lần phân tách. 3 là giá trị phổ biến nhất của N và chúng ta có kiến trúc 3 tầng. Việc phân lớp này có thể giúp phân tách các mối quan tâm, chia nhỏ giải pháp thành các đơn vị nhỏ hơn để mỗi đơn vị chịu trách nhiệm cho một nhiệm vụ cụ thể và cũng tận dụng lợi thế của tính trừu tượng. Đối với các dự án có quy mô từ trung bình đến lớn hơn, nơi nhiều nhóm làm việc, phân lớp có những lợi thế rất rõ ràng. 

Trong chương này, chúng tôi sẽ đề cập đến kiến trúc hành tây sử dụng API Web Asp.Net 6. Thuật ngữ kiến trúc Onion do Jeffrey Palermo giới thiệu vào năm 2008, kiến trúc này cung cấp cho chúng ta một cách tốt hơn để xây dựng các ứng dụng bằng cách sử dụng kiến trúc này, các ứng dụng của chúng tôi có thể kiểm tra tốt hơn, có thể bảo trì và đáng tin cậy trên các cơ sở hạ tầng như cơ sở dữ liệu và dịch vụ. Kiến trúc Onion giải quyết các vấn đề phổ biến như ghép và tách các mối quan tâm.

Kiến trúc Onion là gì?

Trong kiến trúc củ hành, chúng ta có lớp Domain, lớp Repository lớp Service và lớp Presentation. Kiến trúc Onion giải quyết vấn đề mà chúng ta gặp phải trong các ứng dụng doanh nghiệp như phụ thuộc và tách biệt các mối quan tâm. Kiến trúc onion cũng giải quyết vấn đề mà chúng ta gặp phải trong kiến trúc ba tầng và kiến trúc N-Layer. Trong kiến trúc Onion, lớp của chúng ta giao tiếp với nhau bằng các interface.

Các lớp trong kiến trúc Onion

Kiến trúc Onion sử dụng khái niệm lớp, nhưng nó khác với kiến trúc N-layer và kiến trúc 3-Tier.

Domain Layer: Lớp này nằm ở trung tâm của kiến trúc nơi chúng ta có các thực thể (entity) của ứng dụng gồm các lớp application model của ứng dụng hoặc các lớp database model phụ thuộc vào cách tiếp cận về code trong quá trình phát triển ứng dụng. Trường hợp sử dụng ASP.NET, các thực thể này được sử dụng để tạo các bảng trong cơ sở dữ liệu (database model)

Repository Layer: Lớp repository hoạt động như một lớp trung gian giữa lớp service và các đối tượng mô hình, chúng ta sẽ thực hiện các lớp model và database context trong lớp này. Chúng ta sẽ thêm các interface bao gồm các thao tác truy cập dữ liệu cho các thao tác đọc và ghi với cơ sở dữ liệu.

Service Layer: Lớp này được sử dụng để giao tiếp với lớp presentation và repository. Lớp service chứa tất cả logic nghiệp vụ của thực thể (entity). Trong lớp này, các service interface được giữ tách biệt với việc triển khai chúng để các lớp ít phụ thuộc vào nhau

Presentation Layer:  Tương tự như lớp Presentation trong kiến trúc 3 tầng. Nhiệm vụ chính của lớp này là hiển thị dữ liệu với người dùng. Trong trường hợp lớp Presentation API dữ liệu đối tượng từ cơ sở dữ liệu được truyền tải thông qua HTTP request dưới dạng json. Trong trường hợp ứng dụng giao diện người dùng, chúng ta có thể trình bày dữ liệu bằng cách gọi APIs.

Ưu điểm của kiến trúc Onion

• Kiến trúc Onion cung cấp cho chúng ta khả năng bảo trì code tốt hơn vì code phụ thuộc vào các lớp
• Nó cung cấp khả năng kiểm thử tốt cho các unit tests, chúng ta có thể viết các test cases riêng biệt theo lớp mà không ảnh hưởng đến mô-đun khác trong ứng dụng.
• Với kiến trúc onion, các lớp trong ứng dụng sẽ không phụ thuộc lẫn nhau vì các lớp giao tiếp với nhau một cách trừu tượng (thông qua interface)
• Các domain entity là cốt lõi và trung tâm của kiến trúc và có quyền truy cập vào cơ sở dữ liệu và Lớp UI.
• Lớp bên trong không bao giờ phụ thuộc vào lớp bên ngoài (chiều phụ thuộc từ bên ngoài vào trong)

Tổng kết

Trong chương này, chúng ta đã tìm hiểu về kiến trúc Onion chúng ta đã có kiến thức về cách lớp giao tiếp với nhau trong kiến trúc Onion. Bây giờ chúng ta có thể phát triển dự án của mình bằng cách sử dụng kiến trúc onion cho Phát triển API hoặc MVC.