पाठ 26 / 26
Revision: Cheat Sheet और Self-Check
पूरे कोर्स के commands, concepts और परीक्षा में पूछे जाने वाले आम सवालों की दोहराई करें।
Cheat sheet
CLI: new, run, build, test, publish। Pipeline: middleware का क्रम मायने रखता है। DI: transient, scoped (प्रति request), singleton। EF Core: DbContext, migrations, AsNoTracking, N+1 से बचें। Security: input जाँचें, ProblemDetails, HTTPS के साथ JWT। Ship: multi-stage Dockerfile, health checks, पहले मापें।
इंटरव्यू में पूछे जाने वाले सवाल
इन्हें समझाने के लिए तैयार रहें: SDK और runtime का फ़र्क़, middleware का क्रम व्यवहार को कैसे बदलता है, singleton scoped service क्यों नहीं पकड़ सकता, async/await threads कैसे मुक्त करता है, और N+1 query कैसे खोजें व ठीक करें।
त्वरित जाँच: एक singleton service को DbContext चाहिए। सही उपाय क्या है?
- DbContext को static field बनाएँ
- IServiceScopeFactory या DbContextFactory inject करें और हर उपयोग पर scope बनाएँ
- सब कुछ singleton register करें
- Scope validation बंद करें
Answer
IServiceScopeFactory या DbContextFactory inject करें और हर उपयोग पर scope बनाएँ — हर operation पर अल्पकालिक scope या context बनाने से captive dependency से बचाव होता है और DbContext साझा नहीं होता।
त्वरित जाँच: आपकी API ग़लत user input पर 500 लौटाती है। सबसे अच्छा बदलाव क्या है?
- Exception पकड़कर 200 लौटाएँ
- कुछ log न करें
- Input validate करें और ProblemDetails के साथ 400 लौटाएँ
- Server restart करें
Answer
Input validate करें और ProblemDetails के साथ 400 लौटाएँ — Client की ग़लतियाँ 4xx responses हैं; 500 का मतलब असली server ग़लती होना चाहिए।
त्वरित जाँच: async/await के बारे में कौन-सा कथन सही है?
- यह हर await पर नया thread बनाता है
- I/O का इंतज़ार करते समय thread को दूसरा काम करने देता है
- यह CPU-bound कोड को तेज़ बनाता है
- वेब ऐप में इससे बचना चाहिए
Answer
I/O का इंतज़ार करते समय thread को दूसरा काम करने देता है — `await` I/O के इंतज़ार में thread को छोड़ देता है। यह CPU-bound काम को तेज़ नहीं करता।