Theory
Settings कहाँ जाती हैं?
FestConnect को एक database connection string चाहिए, और शायद कुछ और settings: एक admin email, एक page size, क्या site maintenance mode में है। ये कहाँ रहनी चाहिए? आपकी compiled C# के अंदर buried नहीं, क्योंकि फिर database server बदलने का मतलब होगा code edit करना और पूरे app को rebuild करना।
ASP.NET का answer web.config है: application के लिए एक single settings file। यह lesson cover करता है यह क्या hold करता है और configuration को code से बाहर रखना इतनी अच्छी habit क्यों है।
Theory
web.config क्या है
web.config एक XML file है जो आपकी ASP.NET application configure करती है। यह application के root folder में बैठती है (और कोई भी subfolder उस area के लिए settings override करने के लिए अपनी own रख सकता है)।
जो चीज़ें यह commonly hold करती है उनमें: connectionStrings (database तक कैसे पहुँचें), appSettings (आपकी own custom key-value settings), authentication और authorization rules (कौन क्या access कर सकता है), custom error pages, और session settings। यह वह एक जगह है जहाँ देखना है app कैसे configured है। Crucially, ASP.NET इसे runtime पर पढ़ता है, तो एक setting बदलने को code recompile करने की ज़रूरत नहीं।
Practical
A slice of FestConnect's web.config
<configuration>
<connectionStrings>
<add name="FestDb"
connectionString="Server=.;Database=FestConnect;Trusted_Connection=True;" />
</connectionStrings>
<appSettings>
<add key="AdminEmail" value="admin@festconnect.example" />
<add key="EventsPerPage" value="10" />
</appSettings>
</configuration>This example runs in Gri-Learn on the web, where you can edit it and see the output.
Practical
Reading those settings in code
// Read the connection string by name (not hard-coded in the C#)
string cs = ConfigurationManager.ConnectionStrings["FestDb"].ConnectionString;
// Read a custom setting
string adminEmail = ConfigurationManager.AppSettings["AdminEmail"];
int perPage = int.Parse(ConfigurationManager.AppSettings["EventsPerPage"]);Formula
Configuration, Code नहीं
web.config का point configuration को code से separate रखना है। Settings जो बदल सकती हैं, especially आपकी development machine और real server के बीच, config file में रहती हैं, और आपका code इन्हें नाम से पढ़ता है।
तो FestConnect को एक नए database server पर move करना web.config में एक one-line edit है, कोई code change और कोई rebuild नहीं। यही 'इसे एक बार, सही जगह पर define कीजिए' principle है जो code-behind और master pages के पीछे है, settings पर applied।
Quiz
अपने C# code में directly लिखने की बजाय database connection string को web.config में क्यों रखें?
- क्योंकि C# text strings hold नहीं कर सकती
- ताकि connection को code edit या recompile किए बिना बदला जा सके, और यह एक known जगह में रहे
- क्योंकि web.config code से faster चलता है
- क्योंकि connection strings server पर allowed नहीं हैं
Show the answer
ताकि connection को code edit या recompile किए बिना बदला जा सके, और यह एक known जगह में रहे
Connection string को web.config में रखना मतलब है आप इसे बदल सकते हैं, उदाहरण के लिए एक अलग database server पर move करते समय, अकेले config file edit करके, कोई code change और कोई recompile नहीं, और हर किसी को यह एक जगह पता है जहाँ इसे ढूँढना है। Option A nonsense है: C# strings ठीक handle करती है; issue maintainability है, capability नहीं। Option C wrong है: web.config एक settings file है, कुछ ऐसा नहीं जो 'faster चलता है'; performance reason नहीं है। Option D invented है। Real benefit configuration को code से separate करना है: settings जो vary करती हैं (especially आपकी machine और production के बीच) config में belong करती हैं, runtime पर नाम से read होती हैं।
Think first
जब आप Settings को App में Hard-Code करते हैं तो क्या टूटता है?
मान लीजिए आप connection string को हर page पर सीधा अपने C# में paste करते हैं। बाद में क्या ग़लत होता है? फिर tap कीजिए।
Show the answer
कई painful चीज़ें। पहले, MOVING या CHANGING एक code edit बन जाता है: जब आप FestConnect को अपने laptop से college server पर deploy करते हैं, database address बदलता है, और अब आपको code के through hunt करना पड़ता है, हर hard-coded string edit करनी पड़ती है, और पूरी application REBUILD करनी पड़ती है, config की एक line बदलने की बजाय। दूसरा, DUPLICATION और DRIFT: अगर connection string कई files में pasted है, आप eventually एक miss करेंगे, और app का हिस्सा wrong database से बात करेगा। तीसरा, SECURITY और SEPARATION: environment-specific secrets को compiled code में mix करना इन्हें manage करना और source control से बाहर रखना मुश्किल बनाता है। Setting को web.config में centralise करना यह सब fix करता है: एक authoritative value, बिना recompile के changeable, जहाँ भी चाहिए वहाँ नाम से read। यह single source of truth का configuration version है, वही reason जिससे आपने layout को logic से separate किया और styles को centralise किया। जो बदलने वाला है उसे कभी hard-code मत कीजिए।
Summary
Key takeaways
- web.config एक ASP.NET application के लिए एक XML configuration file है, app root में (subfolders override कर सकते हैं)।
- यह connectionStrings, appSettings (custom key-value settings), authentication और authorization rules, custom error pages, और session settings hold करता है।
- ASP.NET इसे runtime पर पढ़ता है, तो एक setting बदलने को कोई recompile नहीं चाहिए।
- Code में settings को नाम से पढ़िए: ConfigurationManager.ConnectionStrings[...] और ConfigurationManager.AppSettings[...]।
- Benefit configuration को code से separate करना है: app edit या rebuild किए बिना database या एक setting बदलिए।
- Settings hard-coding करना हर move पर code edits, duplication और drift, और security problems cause करता है।
- Memory hook: web.config उन चीज़ों को code से बाहर रखता है जो बदलती हैं।