एंटरप्राइज C#: ऐसा कोड कैसे लिखें जो कोड रिव्यू में शर्मिंदा न करे

एंटरप्राइज C#: बैंक का कोड और पेट-प्रोजेक्ट का कोड दो अलग-अलग ब्रह्मांड क्यों हैं

यदि आप कभी किसी छोटी वेब-स्टूडियो से बड़े निगम या फिनटेक में गए हैं, तो आप हल्के सांस्कृतिक झटके की इस भावना को जानते हैं। कल आप बिना टेस्ट और सिर्फ एक टिप्पणी //TODO: refactor के साथ 'हॉट फिक्स' कमिट कर सकते थे, और आज आपको 20 टिप्पणियों वाला रिव्यू मिलता है, जहां हर पब्लिक मेथड के लिए XML-डॉक्यूमेंटेशन चाहिए, और हर डिपेंडेंसी को DI-कंटेनर में रजिस्टर करना होता है।

C# में एंटरप्राइज डेवलपमेंट 'जल्दी करो' के बारे में नहीं है, बल्कि 'इसे ऐसे करो कि तीन साल बाद भी न टूटे, जब कोड के लेखक को पहले ही नौकरी से निकाल दिया गया हो'। यह पूर्वानुमान, स्केलिंग और अंतहीन कोड रिव्यू के बारे में है। आइए समझते हैं कि C# पर एंटरप्राइज डेवलपमेंट वास्तव में क्या है, और पहले ही हफ्ते में कैसे बाहर न निकलें।

1. आर्किटेक्चर: SOLID कोई फैशनेबल शब्द नहीं, बल्कि कानून है

स्टार्टअप में आप 'मैजिक' स्ट्रिंग्स और 2000 लाइनों वाली विशाल क्लासेस के साथ मोनोलिथ बना सकते हैं। एंटरप्राइज में नहीं। यहां SOLID का हर सिद्धांत कोई अमूर्तता नहीं, बल्कि कार्रवाई के लिए मार्गदर्शन है।

एकल उत्तरदायित्व का सिद्धांत (SRP)

आपकी क्लास को यह नहीं पता होना चाहिए कि ईमेल कैसे भेजें, डेटाबेस में कैसे सेव करें और एक साथ XML कैसे पार्स करें। यदि आप एक क्लास में तीन या अधिक 'जिम्मेदारियां' देखते हैं - तो यह एक बुरी गंध है। एंटरप्राइज में ऐसे कोड को 'SRP का उल्लंघन, फिर से लिखें' फॉर्मूलेशन के साथ कोड रिव्यू में वापस कर दिया जाएगा। खराब कोड का उदाहरण:

public class OrderService\n{\n    public void ProcessOrder(Order order)\n    {\n        // 1. वैलिडेशन\n        // 2. DB में सेव करना\n        // 3. ईमेल भेजना\n        // 4. लॉगिंग\n    }\n}

सही तरीका - अलग-अलग सर्विसेज में विभाजित करना और Mediator या Pipeline पैटर्न का उपयोग करना है:

public class ProcessOrderCommandHandler : IRequestHandler<ProcessOrderCommand, bool>\n{\n    private readonly IOrderRepository _repo;\n    private readonly IEmailService _email;\n    private readonly ILogger<ProcessOrderCommandHandler> _logger;\n\n    public ProcessOrderCommandHandler(IOrderRepository repo, IEmailService email, ILogger<ProcessOrderCommandHandler> logger)\n    {\n        _repo = repo;\n        _email = email;\n        _logger = logger;\n    }\n\n    public async Task<bool> Handle(ProcessOrderCommand request, CancellationToken cancellationToken)\n    {\n        var order = await _repo.GetByIdAsync(request.OrderId);\n        // लॉजिक\n        await _email.SendAsync(order.CustomerEmail, "Order processed");\n        _logger.LogInformation("Order {Id} processed", order.Id);\n        return true;\n    }\n}

ध्यान दें: प्रत्येक सर्विस बिल्कुल एक काम करती है। ऐसे कोड का परीक्षण करना कहीं अधिक आसान है।

2. Dependency Injection - आपका सबसे अच्छा दोस्त

C# पर एंटरप्राइज प्रोजेक्ट्स में आप लगभग कभी भी क्लास के अंदर new MyService() नहीं देखेंगे। इसके बजाय - DI-कंटेनर (आमतौर पर Autofac या बिल्ट-इन Microsoft.Extensions.DependencyInjection)।

नियम सरल है: यदि कोई क्लास अपनी डिपेंडेंसी खुद बनाती है - तो वह Dependency Inversion Principle का उल्लंघन करती है। एंटरप्राइज में इसे आर्किटेक्चरल गलती माना जाता है। उदाहरण:

// ❌ खराब: कठोर कपलिंग\npublic class ReportGenerator\n{\n    private readonly PdfExporter _exporter = new PdfExporter();\n    public byte[] Generate() => _exporter.Export();\n}\n\n// ✅ अच्छा: डिपेंडेंसी इनवर्जन\npublic class ReportGenerator\n{\n    private readonly IExporter _exporter;\n    public ReportGenerator(IExporter exporter) => _exporter = exporter;\n    public byte[] Generate() => _exporter.Export();\n}

स्टार्टअप में रजिस्ट्रेशन:

services.AddScoped<IExporter, PdfExporter>();\nservices.AddScoped<ReportGenerator>();

इसकी आवश्यकता क्यों है? पहला, टेस्ट: आप IExporter को मॉक कर सकते हैं और जनरेट नहीं कर सकते