1. Tạo sao phải tuân theo một kiến trúc

Để duy trì sự ngăn nắp, đúng đắn về cấu trúc trong các giải pháp từ trung bình đến lớn hơn, bạn luôn nên tuân theo một số loại kiến trúc. Chắc hẳn bạn đã thấy hầu hết các Project có nguồn mở đều có nhiều Layers trong Project với một cấu trúc thư mục phức tạp.

2. Layer và Tiers

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. Trong bài viết này, chúng ta sẽ xử lý Layered Architecture.

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. Nó cho phép một nhóm hoặc cá nhân cụ thể làm việc trên một Layer cụ thể mà không làm ảnh hưởng đến tính toàn vẹn của những người khác. Việc theo dõi các thay đổi bằng cách sử dụng kiểm soát nguồn dễ dàng hơn nhiều. Ngoài ra, nó còn làm cho toàn bộ giải pháp của bạn trông sạch sẽ.

Trước khi tìm hiểu về Kiến trúc Onion trong ASP.NET Core, chúng ta hãy khái quát lại kiến thức của mình về Kiến trúc N-Layer nhé.

3. Khái quát ngắn gọn về kiến trúc N-Layer

Chúng ta hãy xem xét một kiến trúc phổ biến nhất trong các ứng dụng ASP.NET Core. Dưới đây là một biểu diễn sơ đồ đơn giản về một biến thể của kiến trúc N-Layer. Presentaion Layer thường biểu diễn phần dành cho người dùng có thể tương tác. Business Logic là phần quan trọng nhất trong toàn bộ thiết lập này. Nó chứa tất cả logic liên quan đến các yêu cầu nghiệp vụ. Hầu hết mọi ứng dụng đều có Cơ sở dữ liệu chuyên dụng của riêng mình. Để truy cập Cơ sở dữ liệu, Data Access Layer sẽ đảm nhiệm việc này, tầng này thường chứa các ORM để ASP.NET tìm nạp/ghi vào cơ sở dữ liệu.

3. Nhược điểm của kiến trúc N-Layer

Để hiểu rõ những ưu điểm của Onion Architecture trong ASP.NET Core Applications, chúng ta sẽ cần nghiên cứu các vấn đề với N-Layer Architecture. Đây là một trong những Kiến trúc giải pháp được sử dụng phổ biến nhất trong số các lập trình viên .NET. Thay vì xây dựng một cấu trúc tách biệt cao, chúng ta thường kết thúc với một số Layer phụ thuộc vào nhau. Đây là điều thực sự tồi tệ trong việc xây dựng các ứng dụng có thể mở rộng và có thể gây ra sự cố với sự phát triển của codebase.

Để rõ ràng, trong sơ đồ trên, chúng ta có thể thấy rằng lớp trình bày phụ thuộc vào lớp logic, lớp logic này phụ thuộc vào quyền truy cập dữ liệu, v.v. Vì vậy, chúng tôi sẽ tạo ra một loạt các khớp nối không cần thiết. Nó có thực sự cần thiết không? Trong hầu hết các trường hợp, Presentaion Layer cũng sẽ được kết hợp với Data Access layer. Điều này sẽ đánh bại mục đích có kiến ​​trúc sạch sẽ, phải không? Trong Kiến trúc N-Layer, Cơ sở dữ liệu thường là cốt lõi của toàn bộ ưng dụng, tức là nó là lớp duy nhất không phải phụ thuộc vào bất kỳ thứ gì khác. Bất kỳ thay đổi nhỏ nào trong lớp Business Logic hoặc lớp Data Access đều có thể gây nguy hiểm cho tính toàn vẹn của toàn bộ ứng dụng.

4. Giới thiệu kiến trúc Onion

Kiến trúc Onion, được giới thiệu bởi Jeffrey Palermo, khắc phục các vấn đề của kiến ​​trúc phân lớp một cách dễ dàng. Với Kiến trúc Onion, yếu tố thay đổi cuộc chơi là Domain Layer(Entities và các quy tắc Validation mà nó sử dụng phổ biến trong các Business) nằm ở cốt lõi của toàn bộ ứng dụng. Điều này có nghĩa là tính linh hoạt cao hơn và khớp nối ít hơn. Theo cách tiếp cận này, chúng ta có thể thấy rằng tất cả các Layer chỉ phụ thuộc vào các Core Layer.

Đây là cách tôi chia nhỏ cấu trúc của giải pháp được đề xuất. Domain và Application Layer sẽ là trung tâm của thiết kế. Chúng ta có thể gọi các lớp này là Core Layers. Các lớp này sẽ không phụ thuộc vào bất kỳ lớp nào khác.

Domain Layer thường chứa các Entity và Busines Logic. Application Layer sẽ có các interface và types cụ thể của ứng dụng. Sự khác biệt chính là Domain Layer sẽ có các type chung cho toàn bộ nghiệp vụ, do đó cũng có thể được chia sẻ trên các solution khác. Nhưng Application Layer có các type và interface dành riêng cho ứng dụng. Như đã đề cập trước đó, các Core Layer sẽ không bao giờ phụ thuộc vào bất kỳ layer nào khác. Do đó, những gì chúng tôi làm là chúng tôi tạo các interface trong Application Layer và các interface này được triển khai ở các lớp bên ngoài. Điều này còn được gọi là DIP (Dependency Inversion Principle) nguyên tắc đảo ngược phụ thuộc.

Presentation Layer là nơi lý tưởng nhất bạn muốn đặt project mà người dùng có thể truy cập. Đây có thể là một WebApi, Mvc Project, v.v.

Infrustructure Layer phức tạp hơn một chút. Đó là nơi bạn muốn thêm cơ sở hạ tầng của mình. Infrustructure có thể là bất cứ điều gì. Có thể là Entity Framework Core để truy cập DB, lớp để tạo JWT để xác thực hoặc thậm chí là lớp Hangfire. Bạn sẽ hiểu thêm khi chúng ta bắt đầu triển khai Kiến trúc Onion trong Dự án ASP.NET Core WebApi.

5. Triển khai Kiến trúc Onion trong ASP.NET Core WebApi

Để giữ cho mọi thứ đơn giản nhưng thể hiện kiến ​​trúc một cách đầy đủ nhất, chúng ta sẽ xây dựng một ASP.NET Core Web API có khả năng mở rộng khá tốt. Đối với bài viết này, chúng tôi tạo một Web Api chỉ có một thực thể Product. Chúng tôi sẽ thực hiện các Thao tác CRUD trên nó trong khi sử dụng kiến ​​trúc Onion. Điều này sẽ cung cấp cho bạn một bức tranh khá rõ ràng.

Dưới đây là danh sách các tính năng và công nghệ tôi sẽ sử dụng cho thiết lập này.

• Onion Architecture
• Entity Framework Core
• .NET Core 3.1 Library / .NET Standard 2.1 Library / ASP.NET Core 3.1 WebApi
• CQRS / Mediator Pattern using MediatR Library
• Wrapper Class for Responses
• CRUD Operations
• Inverted Dependencies
• SQL Server 2014

Cấu trúc solution

Video hướng dẫn và giải thích chi tiết

Link download source code (Google Drive)

Nguồn tham khảo: https://codewithmukesh.com/blog/onion-architecture-in-aspnet-core/