ADO.NET DataSet – Features of Disconnected Object

ADO.NET DataSet: किसी Enterprise Application में एक ही Database को बहुत सारे Client Applications Network के माध्‍यम से समान समय पर Access व Manipulate करते हैं जबकि ये Client Applications समान Office में भी हो सकते हैं, जो कि Intranet से Connected हों, जबकि विभिन्न देशों में भी हो सकते हैं जो कि Internet के माध्‍यम से Connected हों।

इस प्रकार के Multi-User Scenario में जब कोई Client किसी Data को Access कर रहा होता है, तब Database पर उस Client के लिए तब तक Connection Open रहता है, जब तक कि उसका काम पूरा नहीं हो जाता। इस स्थिति में यदि कोई अन्य User उसी Database से किसी Data की Request करे, तो Database पर एक अलग Connection Open होता है।

परिणामस्वरूप Database का Performance प्रभावित होता है क्योंकि Database पर जितने ज्यादा Connections Open होते हैं, Database को उतने ही ज्यादा Resources को Use करना पडता है। जबकि Database पर एक User द्वारा किसी काम को पूरा करने के लिए जो Connection Open किया जाता है, Database उस Connection पर User से अगली Request प्राप्त करने के लिए ज्यादातर समय Wait ही करता रहता है।

उदाहरण के लिए यदि एक User pubs Database पर सभी Authors की List प्राप्त करने के लिए Request Perform करता है, तो Open होने वाला Connection तब तक Open रहता है, जब तक कि वह User उस Application को Use कर रहा होता है, फिर भले ही वह User Underlying Database पर कोई भी दूसरी Query Fire न करे। यानी जब तक Application Open रहता है, Database उस Connection पर और Requests प्राप्त होने का Wait करता रहता है, जब तक कि User उस Application को पूरी तरह से Shutdown नहीं कर देता।

इस स्थिति में Database उस Particular Connection पर कोई भी उपयोगी काम नहीं करता बल्कि वह Connection बेवजह ही Resources को तब तक Occupy करके रखता है, जब तक कि User स्वयं ही Application को Close न कर दे। ये स्थिति एक प्रकार से Underlying Database की Performance को ही प्रभावित करता है क्योंकि Database पर जितने ज्यादा Users Connection Open करेंगे, Database उतने ही ज्यादा Resources Use करेगा और Database पर जितने ज्यादा Connections Open होंगे, Database की Data Serving की Speed उतनी ही कम होती जाएगी, फिर चाहे User Underlying Database पर कोई उपयोगी काम करे चाहे न करे।

इस समस्या से बचने का एक ही तरीका है और वह तरीका ये है कि हर User के लिए Database पर एक ही बार Connection Open हो और Connection Open होते ही Underlying Database की एक Logical Copy उस Client के लिए Locally Available हो जाए तथा एक बार पूरे Database का Local Copy, Local Client Application को प्राप्त हो जाने के बाद Underlying Database से Physical Connection Close हो जाए।

परिणामस्वरूप जब हर Client Application का स्वयं का Logical Database उसके स्वयं के Local Application पर Available होगा, तो User जब भी किसी जरूरत को पूरा करने के लिए Underlying Database पर फिर से कोई Query Fire करेगा, तो उस Query से Generate होने वाले Result को सबसे पहले Locally Available Database पर Fire किया जाएगा और यदि उस Local Copy से User की Requirement पूरी हो जाती है, तो Database पर नया Connection Open नहीं किया जाएगा।

इस तरह से User को उसका Required Data भी प्राप्त हो जाएगा जबकि User के Client Application का Underlying Database के साथ Physical Connection भी Open नहीं करना पडेगा। ये तरीका एक प्रकार के Disconnected Scenario को Represent करता है और Client Application में जिस Object के माध्‍यम से Underlying Database की Local Copy प्राप्त होती है, उसे ADO.NET Architecture में DataSet Object के नाम से जाना जाता है।

ADO.NET DataSet – Features of Disconnected Object

Disconnected Scenario में Normal तरीके से काम करने के लिए DataSet जैसे Disconnected Object में कुछ जरूरी Features का Available होना जरूरी होता है। इन जरूरी Features को हम निम्नानुसार Specify कर सकते हैं:

Serializable

किसी Object को Serializable Object तब कहा जाता है, जबकि उस Object में Memory या Data की स्थिति (State) को Bytes के Stream के रूप में Save करने की क्षमता हो, जिसे बाद में जरूरत के अनुसार Read किया जा सके व Cross Machine Mode में यानी किसी अन्य Computer System पर किसी अन्य Computer Application द्वारा भी Process किया जा सके।

Disconnected Scenario में काम करते समय हमें अक्सर Data के Subset को Network, Process व Machine Boundaries के Across Send करने की जरूरत होती है। इस जरूरत को आसानी से पूरा करने के लिए ही Object का Serializable होना जरूरी होता है।

XML Supported

हालांकि Object की Serialization की क्षमता काफी उपयोगी होती है लेकिन Serialization को Binary Form में भी Perform किया जा सकता है। जबकि Binary Format हम Human Beings के लिए Readable नहीं होता। इस वजह से XML के रूप में एक ऐसे Universal Format को Develop किया गया है, जिसे न केवल विभिन्न प्रकार के Processor Architectures Based Machines व Operating Systems बल्कि हम Human Beings भी आसानी से समझ सकते हैं।

हालांकि Wireless Networks पर ये Format कभी-कभी Suitable नहीं होता, लेकिन फिर भी Text Based Format होने की वजह से इसे Parse करने हेतु सभी Operating Systems के लिए Parsers Exist हैं। इसलिए Disconnected Scenario में काम करने वाले Object में XML Format को Access व Manipulate करने की भी क्षमता होनी चाहिए।

History of Changes Maintainable

Database से Data की Query करने के साथ ही Database में नए Data को Update भी किया जाता है, जबकि Database में किए जाने वाले Changes को Perform करते समय Concurrency Related Issues को भी ध्‍यान में रखना होता है, जो कि Database की Query करने की तुलना में ज्यादा जटिल काम होता है।

इसलिए बेहतर यही होता है कि Disconnected Mode में Use होने वाले Object में ये क्षमता हो कि उसके माध्‍यम से Database में जिन Changes को Perform किया गया है, उन Changes की History को भी वह Object Maintain कर सके, ताकि Concurrency Related Issues को बेहतर तरीके से Handle किया जा सके।

पिछले Chapter में हमने ArrayList Object को Use करते हुए एक किया था। हालांकि ArrayList Object DataSet की तुलना में काफी Light Weight Object होता है, लेकिन ये Object उपरोक्तानुसार Discussed तीन में दो अन्तिम दो Characteristics को Follow नहीं करता। यानी ArrayList Object XML को Support नहीं करता और इसके माध्‍यम से Underlying Database में जिन Changes को Perform किया जाता है, उन Changes की History को Maintain नहीं करता। हालांकि कुछ परिस्थितियों में ArrayList Object, DataSet Object की तुलना में Data Updating के लिए बेहतर Choice होता है।

उदाहरण के लिए यदि हमें XML Flexibility की जरूरत न हो अथवा यदि हम केवल Read-Only System पर काम कर रहे हों, जो कि केवल Underlying Database के Data को Read ही कर रहा हो, जैसाकि किसी Web Application में किसी Data को केवल Render करने के लिए ही Underlying Database से Access किया जा रहा हो, या हमें Database Updating के बाद इस बात को Confirm करने के लिए ही Underlying Database को Access करना हो कि Specified Changes Underlying Database पर Perform हुए या नहीं, इस प्रकार की स्थितियों में DataSet Object के स्थान पर ArrayList Object ज्यादा उपयोगी साबित होता है।

सरल शब्दों में कहें तो जब हमें Underlying Database के Data को केवल Presentation के लिए ही Access करना हो Updating के लिए नहीं, तब हमें DataSet Object के स्थान पर ArrayList Object का ही प्रयोग करना चाहिए।

लेकिन यदि हमारी Requirement को ArrayList Object द्वारा पूरा न किया जा सकता हो, जो कि तब होता है, जब हम हमारे Underlying Database को Frontend के माध्‍यम से Update भी करना चाहते हैं, तो इस प्रकार की स्थिति में Business Object Representation Create करने की जरूरत पडती है जो कि उपरोक्तानुसार तीनों Characteristics को Satisfy करता हो और यदि हम चाहें तो इस प्रकार की तीनों Characteristics से युक्त एक अलग नया Object Create करने के स्थान पर ADO.NET द्वारा Provided DataSet Object को Use कर सकते हैं, जो कि उपरोक्त तीनों Features को Support करता है।

उदाहरण के लिए जब हम Disconnected Data के साथ प्रक्रिया कर रहे होते हैं, तब हमें एक बात का विशेष रूप से ध्‍यान रखना होता है कि हम जिस Disconnected Data के साथ प्रक्रिया कर रहे हैं, वह Underlying Database के Data की एक Currently Updated व Refreshed Copy हो।

यानी हमें इस बात का ध्‍यान रखना होता है कि Enterprise Application के Distributed Mode में कोई भी Client यदि Underlying Database में किसी भी तरह का Change करे, तो हमारे Application में उस Changed Data की Currently Updated व Refreshed Copy Maintain रहे ताकि हमारा Application हमेंशा Disconnected Mode में भी Underlying Database के Latest Data को ही Return करे और DataSet Object में ये Mechanism In-Built है, जिसकी वजह से किसी भी तरह से कभी भी यदि Underlying Database में किसी भी तरह का Change या Update होता है, तो DataSet Object Automatically नए Data से Update हो जाता है।