Clean Architecture (Mô hình nhiều lớp) với .NET Core Web App (MVC)

[Mr_HIE_02 (dthieu02)]

Xin chào mọi người,

Mình đang triển khai project .NET Core Web App (MVC) với mô hình nhiều lớp như sau:

— Controller Layer —

• Xử lý HTTPRequest, HTTPResponse, Localization.

• Sử dụng các instance của Services Layer.

— Service Layer —

• Chứa các business logic.

• Sử dụng các instance của Repository Layer (Vd services A chỉ dùng Repo A).

• Sử dụng các instance của các Services khác. (Cần để ý đến circular dependency crash)

— Repository Layer —

• Đóng gói EF-Core, định nghĩa các thao tác lấy dữ liệu dưới DB.

• Mỗi Repo đóng vai trò kiểm soát dữ liệu cụ thể (vd ProductRepo, BookInfoRepo, BookDetailRepo, …) hay cụ thể là mỗi entity một Repo.

Khi triển khai mô hình trên, em thấy mô hình làm ra rất clear, dễ dàng fixbug hoặc scale khi khách hàng có thay đổi yêu cầu - logic hoặc cấu trúc dữ liệu.

Nhưng việc triển khai này khá tốn thời gian - phải khai báo nhiều interface + class - register DI, và đôi khi em thấy tầng Repository hơi vô dụng (vì phải khai báo quá nhiều).

VD:
Khi với trường hợp Data1, với mỗi file Data1 import là thông tin của file (info) và dữ liệu đã import (detail) -> sinh ra 2 repo.

Em thấy nhiều lúc khá băn khoăn và thấy mình áp dụng chưa đúng hoàn cảnh. Em cũng có tham khảo thêm mô hình DDD, nhưng vẫn chưa có lời giải cho cấu trúc dự án.

Có lẽ em không nên đóng gói DBContext lại (vì sở dĩ DBContext hay DBSet<> là 1 Repository). Có ai từng gặp trường hợp như em không ạ.

Đôi khi em cảm thấy mình đang ‘dùng dao mổ trâu để giết gà chăng’,
hay từ khi mình tìm hiểu áp dụng các Design Pattern, sự lo lằng về Tight couping, về Single Responsibility đã thấm nhuần vào tư tưởng, cách triển khai các vấn đề.

Rất vui nếu được mọi người đón nhận và chia sẻ, góp ý cho em, em xin cảm ơn.
Cảm ơn nếu đã dành thời gian quan tâm đến vấn đề của em.

[Joe (Schwarz)]

Do you know why the West made progress in the past while China (and Vietnam) lagged behind, and still do?

It’s because a Westerner did what he thought was right and enhanced or corrected the mistakes, while a Chinese or Vietnamese person simply memorized and didn’t dare to do what he believed was better. Instead, he sought advice from others .

Many Chinese and Vietnamese scholars invented and developed well in the West, but in their home country they became lackluster.

• An Wang was born in Shanghai and studied in Boston. He was the first to develop computer memory based on magnetic cores and built the Wang computer, which enabled the first word processing.
• Charles K. Kao is considered the father of fiber optic development and transmission in telecommunications. He worked for STC (Standard Telephones and Cables Ltd.) in London.
• Bui Tuong Phong, a South Vietnamese national, studied in the USA (Utah) and is considered the father of 3D imaging, also known as Phong Shading.
• Do Duc Cuong, a Vietnamese-American inventor, is the creator of the globally ubiquitous ATM.

So why not believe in yourself? If something isn’t working out the way you envisioned, it presents the perfect opportunity to improve or redesign it. Don’t be confused or misled by empty buzzwords like “design patterns,” “tight coupling,” or “individual responsibility”, etc.

[tonghoangvu (Vu Tong)]

@Mr_HIE_02

Mỗi Repo đóng vai trò kiểm soát dữ liệu cụ thể (vd ProductRepo, BookInfoRepo, BookDetailRepo, …) hay cụ thể là mỗi entity một Repo.

@Mr_HIE_02

Khi với trường hợp Data1, với mỗi file Data1 import là thông tin của file (info) và dữ liệu đã import (detail) -> sinh ra 2 repo.

Có vẻ bạn chưa thực hiện repository theo đúng DDD nên mới thấy thừa thãi. Thay vì 1 repository cho 1 entity, thì repository nên được thiết kế dựa trên nhu cầu của business layer, và trong repository đó sẽ phải manipulate trên nhiều entity khác nhau để làm được điều đó.

Ví dụ business cần get thông tin file + detail, thì chỉ cần 1 repository method duy nhất là getDataFileWithDetails(), còn trong impl thì bạn có thể dùng DbContext để query (xài 2 query riêng biệt hoặc 1 query với join đều được). Cuối cùng là tổng hợp lại và return về cho business layer.

Đọc thêm: https://voz.vn/t/thao-luan-repository-pattern-la-cai-bullsh-t-nhat-khi-đa-co-orm-framework.490455/

[TranMinhHoang (Trần Minh Hoàng)]

Controller + Service Layer là đủ

[Joe (Schwarz)]

@Mr_HIE_02

Khi triển khai mô hình trên, em thấy mô hình làm ra rất clear, dễ dàng fixbug hoặc scale khi khách hàng có thay đổi yêu cầu - logic hoặc cấu trúc dữ liệu.

Like I said, if you think it’s better, then just stick with it. Why ask for advice? Do you really think any “consultant” is better? It’s your work, your signature style, and if the clients are happy, you’ve developed it, and your clients will tell your boss about their satisfaction—you’ll become a valuable and indispensable employee in the eyes of your employer.

@Mr_HIE_02

Nhưng việc triển khai này khá tốn thời gian - phải khai báo nhiều interface + class - register DI, và đôi khi em thấy tầng Repository hơi vô dụng (vì phải khai báo quá nhiều).

Nothing comes from nothing. Every task takes time. A lazy developer is one who keeps things simple. Simplicity is the key to any successful work. The famous Russian Mikhail Kalashnikov often expressed his philosophy that simplicity and reliability are paramount in design: “Things that are complex are not useful, Things that are useful are simple.” Your problem is how to streamline, rationalize and simplify the workload.

@Mr_HIE_02

Đôi khi em cảm thấy mình đang ‘dùng dao mổ trâu để giết gà chăng’,
hay từ khi mình tìm hiểu áp dụng các Design Pattern, sự lo lằng về Tight couping, về Single Responsibility đã thấm nhuần vào tư tưởng, cách triển khai các vấn đề.

If you always pay attention to the others opinion, you enslave yourself to doubt and dependency. Forget all the bullshits about Design Pattern, Tight Coupling or Simple Responsibility. They are merely approaches to rationalize, streamline and simplify the workload. They are there to give you ideas, but they are not a paradigm you have to follow.