Thím có thể share cái architecture thực tế được không, em có coi cái architecture của thằng aspnetboilerplate mà thấy nó hơi rối, không biết trong thực tế mọi người implement thằng microservice này sao![]()
private readonly DataContext _dataContext;
public PostService(DataContext dataContext)
{
_dataContext = dataContext;
}
//PostService cần dependency DbContext (Entity)
//Vì sao không nên register PostService như sau (Ở Startup class)
services.AddSingleton<IPostService, PostService>();
À mình cũng dùng cái này nè, mà cái này không hiểu sao mình xài AllowAnyMethod thì cái Method Put nó chặn, báo lỗi CORS, còn GET với POST thì ok, không biết phải do IIS không nữaMình hay thêm cái này
C#:public void ConfigureServices(IServiceCollection services) { services.AddCors(options => { options.AddPolicy("AllowAnyOrigin", builder => builder .AllowAnyOrigin() .AllowAnyMethod() .AllowAnyHeader()); }); ... } public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseCors("AllowAnyOrigin"); ... }
Trong Asp .Net Core thì khi register service của thằng EntityFramework mặc định life cycle của nó là Scope, cho mình hỏi là tại sao 1 thằng Service khác cần cái Dependency của thằng EntityFramework kia không nên Register kiểu AddSingleton? Mình có hiểu cái Life Cycle Scope với Singleton mà không tự giải thích được.
C#:private readonly DataContext _dataContext; public PostService(DataContext dataContext) { _dataContext = dataContext; } //PostService cần dependency DbContext (Entity) //Vì sao không nên register PostService như sau (Ở Startup class) services.AddSingleton<IPostService, PostService>();
Xem tệp đính kèm 25102
Trong Asp .Net Core thì khi register service của thằng EntityFramework mặc định life cycle của nó là Scope, cho mình hỏi là tại sao 1 thằng Service khác cần cái Dependency của thằng EntityFramework kia không nên Register kiểu AddSingleton? Mình có hiểu cái Life Cycle Scope với Singleton mà không tự giải thích được.
C#:private readonly DataContext _dataContext; public PostService(DataContext dataContext) { _dataContext = dataContext; } //PostService cần dependency DbContext (Entity) //Vì sao không nên register PostService như sau (Ở Startup class) services.AddSingleton<IPostService, PostService>();
Xem tệp đính kèm 25102
Hi bác cái bác giải thích em hiểu (Nó giống vs giải thích của MSDN) nhưng vấn đề là em chưa rõ trường hợp cụ thể như thế nào mà khi Singeleton service dùng Scoped Service mà có thể gây ra sai. Cái em không hiểu tại sao đâyKhi một service được register theo kiểu scoped, tức là mình muốn mỗi request sẽ dùng riêng 1 instance của service đó để xứ lí. Vì nhiều request dùng chung 1 instance này có thể chạy sai.
Ví dụ, ở request thứ nhất, singleton service được sử dụng. Lúc này 1 instance của service này được khởi tạo cùng với việc khởi tạo của scoped service để truyền vào singleton service.
Khi request thứ 2 đến, single instance ở request thứ 1 được sử dụng lại mà ko cần khởi tạo. Trong instance này nó lại reference đến thằng scoped service được khởi tạo ở request thứ 1. Vậy là 2 request này đều dùng chung 1 instance của scoped service => Chạy sai.
Hi bác cái bác giải thích em hiểu (Nó giống vs giải thích của MSDN) nhưng vấn đề là em chưa rõ trường hợp cụ thể như thế nào mà khi Singeleton service dùng Scoped Service mà có thể gây ra sai. Cái em không hiểu tại sao đây
Vậy là 2 request này đều dùng chung 1 instance của scoped service
Tại sao dùng chung instance của Scoped Service có thể gây ra sai nhỉ ? Giả sử với request 1 property của scoped service có gì đó thay đổi, thì khi đến với request 2, tuy là vẫn dùng chung object (Cụ thể là reference) thì property cũng được update cái thay đổi đó mà
//Vì thực sự việc dùng chung instance là giữ nguyên cái reference, còn thuộc tính của Scoped Service object vẫn luôn được update 1 cách đúng đắn nếu có thay đổi mà
Nice quá thím ơi, cám ơn thím nhiều nhéVí dụ thím dùng entity framework để thực hiện thao tác dữ liệu trên database đi. Thím register DbContext theo kiểu scoped nhưng inject nó vào 1 singleton service. Ở request thứ nhất, thím gọi:
context.Set<Order>.Add(order);
Lúc này chỉ mới thêm order thôi, chưa gọi context.Save() để nó lưu xuống DB vì thím cần kiểm tra thêm 1 số thứ nữa trước khi lưu.
Song song lúc này, khi xử lí request 2, thím gọi
context.Set<Customer>().Add(customer);
context.Save();
Do context ở 2 request là cùng 1 instance. Nên trong khi xử lí request thứ 2, order lại vô tình được lưu xuống db luôn, mặc dù ở request 1, thím chưa kiểm tra nó xong. Lúc này là chạy sai rồi.
Tiếc là chỉ cho được 1 ưng 
Công ty hiện tại của tôi đang làm microservices đây, chỉ authenticate ở endpoint ngoài cùng thôi, sau đó dùng các api internal để xử lý tiếp, không authenticate/authorize nữa. Dùng jwt asp.net core bình thường thôi.
Hi bác cái bác giải thích em hiểu (Nó giống vs giải thích của MSDN) nhưng vấn đề là em chưa rõ trường hợp cụ thể như thế nào mà khi Singeleton service dùng Scoped Service mà có thể gây ra sai. Cái em không hiểu tại sao đây
Vậy là 2 request này đều dùng chung 1 instance của scoped service
Tại sao dùng chung instance của Scoped Service có thể gây ra sai nhỉ ? Giả sử với request 1 property của scoped service có gì đó thay đổi, thì khi đến với request 2, tuy là vẫn dùng chung object (Cụ thể là reference) thì property cũng được update cái thay đổi đó mà
//Vì thực sự việc dùng chung instance là giữ nguyên cái reference, còn thuộc tính của Scoped Service object vẫn luôn được update 1 cách đúng đắn nếu có thay đổi mà
Giữa các service bác dùng cái gì để xác định user vậy ? Nếu vẫn dùng JWT giữa các service thì vẫn là kiểm tra authenticate tại các service mà


Bạn đọc ở đây nhéGiờ mới biết thread này, lỡ lập thớt ngoài rồi, mấy bác xem giúp mình với.
https://next.voz.vn/t/hoi-ve-asp-net-mvc.20479/