आपको ORM का उपयोग क्यों करना चाहिए? [बन्द है]

Question

यदि आप "पेशेवरों" को प्रेरित करने के लिए थे कि आप ORM को प्रबंधन / ग्राहक के लिए क्यों उपयोग करेंगे, तो इसके क्या कारण होंगे?

कोशिश करें और प्रति उत्तर एक कारण रखें ताकि हम देख सकें कि सबसे अच्छे कारणों के रूप में मतदान क्या होता है

Comments

यदि आप एक पोल चाहते हैं, तो आपको इसे विकी बनाना चाहिए

— फ्रैंककोडियर

+1 अगर आप पोल चाहते हैं तो इसे विकी बनाने के लिए

— cletus

कॉन के बारे में क्या?

— ब्रायन मैथ्यूज

और कोई चम्मच भी नहीं। नहीं, वास्तव में, एक चुनाव है: प्रदर्शन। जब आपको ORM से गुजरना न हो तो DB प्रश्नों को अनुकूलित करना बहुत आसान है। (मैं शिकायत नहीं कर रहा हूं - हाल ही में ओआरएम पर स्विच किया गया है , मैं ज्यादातर इसके साथ खुश हूं; सामान्य उद्देश्य के लिए, ओआरएम जाने का एक तरीका है; लेकिन प्रश्नों को धातु के करीब चलाने के लिए कुछ भी रखें यदि आपको प्रदर्शन की आवश्यकता है)

— पिस्कवर ने

@ UğurGümüşhan, IMHO एक ORM का उपयोग करने का मुख्य लाभ डेवलपर्स को अधिक उत्पादक बनाना है, उन्हें उसी भाषा और OO प्रतिमान में कार्यक्रम देने की अनुमति देता है जो वे अपने ऐप के बाकी हिस्सों में उपयोग करते हैं। जब वे RDBMS संग्रहीत कार्यविधि भाषा में डेवलपर कोड बनाते हैं, तो संग्रहीत कार्यविधियाँ प्रदान नहीं कर सकती हैं। तो वे नहीं कर सकते एक ORM कर सकते हैं सब कुछ करना।

— बिल करविन

Answer 1

डेटा एक्सेस को अधिक अमूर्त और पोर्टेबल बनाना। ओआरएम कार्यान्वयन कक्षाएं विक्रेता-विशिष्ट एसक्यूएल लिखना जानती हैं, इसलिए आपके पास नहीं है।

Comments

हालांकि मैं मानता हूं कि यह ORM की एक विशेषता है, मैं यह प्रस्तावित करूंगा कि उपयोग-मामला काफी सीमित है। मैंने लगभग एक दशक तक MySql और sqlite के लिए वास्तव में कुछ भी इस्तेमाल नहीं किया है। मुझे लगता है कि यह ज्यादातर डेवलपर्स के लिए शायद बहुत दुर्लभ आवश्यकता है।

— troelskn

@troelskn: मैं मानता हूं, मैंने कई RDBMS उत्पादों का उपयोग किया है, लेकिन कभी भी एक या दो से अधिक प्रति प्रोजेक्ट नहीं। तो पोर्टेबिलिटी SQL को अमूर्त करने का सबसे व्यावहारिक मूल्य नहीं है। मुझे लगता है कि कई ORM उपयोगकर्ता बस SQL ​​में कोडिंग से बचना चाहते हैं।

— बिल करविन 19

विक्रेताओं को हर समय नए संस्करण / सुविधाएँ मिलती हैं ... बोली को लिखने और इसे आसान अपग्रेड करने के लिए कुछ शांत लोगों की आवश्यकता होती है!

— डॉटजेओ

विशिष्ट बेकार जवाब मुझे आश्चर्य है कि यह क्यों अच्छा जवाब के रूप में चिह्नित किया गया है, उस आदमी की तरह लगता है जो सवाल पूछता है अपने बॉस को औचित्य देने की कोशिश करता है कि उसे ORM का उपयोग करना चाहिए :) मेरा सवाल यह होगा कि आप हाइबरनेट के साथ किस तरह की समस्या का सामना करेंगे। stackoverflow.com/questions/6477170/…

— user310291

@ user310291: ओपी ने समस्याओं या नुकसान के लिए नहीं पूछा, उन्होंने ओआरएम का उपयोग करने के लाभ के लिए कहा। बेशक पेशेवरों और विपक्ष हैं, लेकिन उन्होंने पेशेवरों के लिए कहा। सच कहूँ तो, मुझे आश्चर्य है कि यह उत्तर स्वीकार कर लिया गया और जितने भी उत्थान हुए, क्योंकि मैं इसे एक ORM के मुख्य लाभ के रूप में नहीं गिना गया।

— बिल करविन

Answer 2

ORM का उपयोग करने का सबसे महत्वपूर्ण कारण यह है कि आपके पास एक समृद्ध, ऑब्जेक्ट ओरिएंटेड बिजनेस मॉडल हो सकता है और फिर भी इसे स्टोर करने में सक्षम हो सकता है और एक रिलेशनल डेटाबेस के खिलाफ जल्दी से प्रभावी क्वेरी लिख सकता है। मेरे दृष्टिकोण से, मुझे कोई वास्तविक लाभ नहीं दिखता है जो एक अच्छा ओआरएम आपको देता है जब आप उन्नत प्रकार के प्रश्नों की तुलना में अन्य उत्पन्न डीएएल के साथ तुलना कर सकते हैं।

मैं जिस प्रकार की क्वेरी के बारे में सोच रहा हूं वह एक बहुरूपिक क्वेरी है। एक साधारण ORM क्वेरी आपके डेटाबेस में सभी आकृतियों का चयन कर सकती है। आपको आकृतियों का संग्रह वापस मिल जाता है। लेकिन प्रत्येक उदाहरण अपने विभेदक के अनुसार एक वर्ग, वृत्त या आयत है।

एक अन्य प्रकार की क्वेरी एक ऐसी होगी जो किसी ऑब्जेक्ट को और एक डेटाबेस डेटाबेस कॉल में एक या एक से अधिक संबंधित ऑब्जेक्ट या संग्रह प्राप्त करती है। उदाहरण के लिए प्रत्येक आकार की वस्तु को उसके शीर्ष और साइड कलेक्शन के साथ लौटा दिया जाता है।

मुझे यहाँ कई अन्य लोगों से असहमत होने का खेद है, लेकिन मुझे नहीं लगता कि ORM के साथ जाने के लिए कोड पीढ़ी अपने आप में एक अच्छा पर्याप्त कारण है। आप कोड जनरेटर के लिए कई अच्छे डीएएल टेम्प्लेट लिख या पा सकते हैं जिनमें वैचारिक या प्रदर्शन ओवरहेड नहीं है जो ओआरएम करते हैं।

या, यदि आपको लगता है कि आपको यह जानने की आवश्यकता नहीं है कि ORM का उपयोग करने के लिए अच्छा SQL कैसे लिखना है, तो, मैं असहमत हूं। यह सच हो सकता है कि एकल प्रश्नों को लिखने के दृष्टिकोण से, ORM पर भरोसा करना आसान है। लेकिन, ORM के साथ खराब प्रदर्शन वाली दिनचर्या बनाना बहुत आसान है, जब डेवलपर्स यह नहीं समझ पाते हैं कि उनके प्रश्न ORM और SQL के साथ कैसे काम करते हैं।

एक डेटा लेयर होना जो कई डेटाबेस के खिलाफ काम करता है, एक फायदा हो सकता है। यह एक ऐसा नहीं है जिस पर मुझे अक्सर भरोसा करना पड़ा है।

अंत में, मुझे यह दोहराना है कि मेरे अनुभव में, यदि आप अपने ORM की अधिक उन्नत क्वेरी सुविधाओं का उपयोग नहीं कर रहे हैं, तो अन्य विकल्प हैं जो कम सीखने और कम सीपीयू चक्रों के साथ शेष समस्याओं को हल करते हैं।

अरे हाँ, कुछ डेवलपर्स ORM के साथ काम करने को मज़ेदार मानते हैं, इसलिए ORM की आपके-डेवलपर्स-खुश रहने के नज़रिए से भी अच्छे हैं। =)

Comments

ख़ूब कहा है। जबकि मूल पोस्टर ने विशेष रूप से "पेशेवरों" और "विपक्ष" के लिए नहीं देखा था, मैंने कुछ हॉरिल एसक्यूएल को देखा है कि आप कैसे ओआरएम का उपयोग करते हैं उनके प्रभाव को समझकर नहीं बनाया गया है। मेरे लिए, सबसे बड़ा लाभ साधारण सीआरयूडी लेनदेन के लिए है जो कि ट्रांजेक्शनल सिस्टम के लिए आपके डीएएल कोड के अधिकांश हैं। मुझे लगता है कि आप शुद्ध ओआरएम और अन्य उत्पन्न डीएएल विधियों के बीच बालों को विभाजित कर रहे हैं। मुझे लगता है कि कुछ भी जो आपको वस्तुओं के बीच अनुवाद करने में मदद करता है और डीबी को ओआरएम माना जा सकता है, यह सिर्फ एक अलग परिचालन मॉडल है।

— डग लैंपे

@ डग - मुझे लगता है कि मैं जो अंतर था, वह यह था कि एक साधारण डीएएल में उत्पन्न सीआरयूडी एसक्यूएल की तुलना में थोड़ा अधिक था, जबकि एक ओआरएम में नेविगेशन गुण, संग्रह दृढ़ता, समर्पित क्वेरी भाषा, कैश आदि जैसे कई और सार शामिल थे - एक बेहतर तरीका। आपके अवलोकन के प्रकाश में मेरी बात को बताते हुए यह हो सकता है कि यह सच है कि ORM की अधिक विशेषताओं का उपयोग करने से आप तेजी से लागू कर सकते हैं, यह उन सुविधाओं से अनभिज्ञ बने रहने के लिए स्वीकार्य नहीं है। शायद इसलिए कि ORM का सार सबसे ज्यादा लीक होता है। ( en.wikipedia.org/wiki/Leaky_abstraction )

— चक

कृपया इसे कुछ और विस्तृत करें: "यदि आप अपने ORM की अधिक उन्नत क्वेरी सुविधाओं का उपयोग नहीं कर रहे हैं, तो अन्य विकल्प हैं जो शेष समस्याओं को हल करते हैं"। हाइबरनेट गेविन किंग के निर्माता के रूप में भी कहते हैं: "वास्तव में, हाइबरनेट जैसी प्रणालियों को जानबूझकर" टपका हुआ सार "के रूप में डिज़ाइन किया गया है ताकि यह आवश्यक हो कि जहां आसानी से देशी एसक्यूएल में मिलाया जा सके। ऑर्डन एब्स्ट्रैक्शन की रिसाव एक विशेषता है, बग नहीं। ! " - reddit.com/r/programming/comments/2cnw8x/…

— जंगल_मोल

1) यह पुराना है। तब, ORM में सभी सुविधाएँ (कैश, क्वेरीज़, बैचिंग, आदि) थीं। IMHO, ऑब्जेक्ट आधारित, बहुरूपी प्रश्न केवल ORM विशेषता थी जो कोड जीन (स्पष्ट ADO मानचित्रण) आसानी से प्रदान नहीं कर सकती थी। 2) जबकि कुछ उपयोगी छेद जानबूझकर छोड़ दिए गए थे, वहाँ भी आवश्यक बुराइयाँ और उन्नत सुविधाएँ थीं जो ORM में एक उच्च शिक्षण वक्र बनाती थीं। इसलिए, मेरा उत्तर ORM के बजाय कोड जीन का उपयोग करना था जब तक कि आपको उन्नत प्रश्नों की आवश्यकता न हो। *) वर्तमान समय में, ओआरएम में पर्याप्त विविधता है कि आपकी टीम के लिए सेट की गई सही सुविधा संभवतः वहां से बाहर है। मेरी टीम अब Linq2DB की शौकीन है।

— चक

Answer 3

विकास को गति देना। उदाहरण के लिए, ऑब्जेक्ट और सदस्यों के विपरीत क्वेरी मैपिंग फ़ील्ड जैसे पुनरावृत्ति कोड को समाप्त करना।

Comments

दोहराव कोड बहुत बुरा है, लेकिन क्या आप एक अमूर्तता का निर्माण नहीं कर सकते हैं जो इसे हटा देगा? उदाहरण के लिए, आपके पास एक तालिका / क्वेरी परिणाम ऑब्जेक्ट हो सकता है जो आपको पीछे की पंक्तियाँ देगा जो आप तब सामान के साथ कर सकते हैं। ORMs DB की चुनी गई अमूर्तता में जाने के बजाय व्यक्तिगत वर्ग के उदाहरणों में पंक्तियों को तोड़ते हुए प्रतीत होते हैं, जो क्वेरी परिणामों की तालिका / पंक्तियाँ हैं। मैं यह नहीं कह रहा हूं कि इसका मतलब है कि ORM अच्छे नहीं हैं, लेकिन मुझे यकीन नहीं है कि यह अकेले उनका उपयोग करने का एक कारण है।

— बेन्जोन

@ बैंजोन, मैं मानता हूं कि ओआरएम समाधान व्यक्तिगत पंक्तियों को वस्तुओं के रूप में मानता है, जबकि आरडीबीएमएस एक इकाई के रूप में पंक्तियों के सेट का व्यवहार करता है। RDBMS मानसिकता में वे चीजें हैं जो आप OO मानसिकता में नहीं कर सकते हैं।

— बिल कार्विन

यह एक पूरी कार खरीदने सिर्फ ट्रंक का उपयोग करने की तरह है, वहाँ दोहराव के साथ काम से बचने के लिए कई तरीके हैं

— mohas

Answer 4

आपके डेटा एक्सेस लेयर में व्यावसायिक नियमों के OO एनकैप्सुलेशन का समर्थन करना। आप अपनी एप्लिकेशन भाषा में व्यावसायिक नियमों को (और डिबग) क्लॉन्की ट्रिगर और संग्रहीत प्रक्रिया भाषाओं के बजाय प्राथमिकता के साथ लिख सकते हैं।

Comments

क्या आप डेटाबेस में अपने व्यावसायिक नियम नहीं रखना चाहते हैं? यह एक डेटाबेस का एक लाभ है, सही: कई ग्राहक DBMS द्वारा प्रदान किए गए एक ही इंटरफ़ेस का उपयोग कर सकते हैं। यदि आपके बहुत सारे इंटरफ़ेस लॉजिक किसी विशेष क्लाइंट के ORM कोड में बंद हैं, तो यह डेटाबेस में नहीं है और अन्य क्लाइंट इसका उपयोग नहीं कर रहे हैं। क्यू फ्रंट ऑफिस बैक ऑफिस ब्रेक (एक क्लाइंट मॉडल दूसरे के साथ लाइन से बाहर हो रहा है)।

— बेन्जोन

@ बेंजोन्ह, मैं बस व्यापार नियमों को डेटाबेस में रखना चाहता हूं, लेकिन घोषणात्मक बाधाओं में अधिक जटिल नियम आसानी से नहीं बनते हैं। उदाहरण के लिए "ग्राहक को पूरे ऑर्डर पर 10% की छूट मिलती है, जब वे पहली बार एक ही ब्रांड के तीन से अधिक जोड़े खरीद लेते हैं।" आप उस व्यावसायिक नियम को डेटाबेस में कैसे रखेंगे (ध्यान रखें कि संग्रहीत प्रक्रियाओं को शामिल करने वाला उत्तर क्लूनी है)।

— बिल करविन

यह 2020 है, मैं किसी को भी संग्रहीत प्रक्रियाओं का उपयोग करते हुए नहीं देखता। तो क्या आप अभी भी खड़े हैं?

— ospider

मुझे लगता है कि मेरी बात यह है कि लोग संग्रहीत प्रक्रियाओं का उपयोग नहीं करते हैं, वे एप्लिकेशन कोड का उपयोग करते हैं। क्या आपने कुछ अलग समझा?

— बिल कार्विन

Answer 5

बुनियादी CRUD संचालन के लिए बॉयलरप्लेट कोड बनाना। कुछ ORM फ्रेमवर्क सीधे डेटाबेस मेटाडेटा का निरीक्षण कर सकते हैं, मेटाडेटा मैपिंग फ़ाइलें पढ़ सकते हैं, या घोषणात्मक वर्ग गुणों का उपयोग कर सकते हैं।

Comments

karwin.blogspot.com/2009/01/why-should-you-use-orm.html

— एंड्रयू ब्रेक्सा

Answer 6

आप अलग डेटाबेस सॉफ़्टवेयर में आसानी से जा सकते हैं क्योंकि आप एक अमूर्त के लिए विकसित कर रहे हैं।

Comments

डेटाबेस काम करने के 30 से अधिक वर्षों में, मुझे एक बार ऐसा नहीं करना पड़ा है।

— एचएलजीईएम

इसका मतलब यह नहीं है यह संभव नहीं है! :)

— मैट फेनलोन

@ HLGEM इसका मतलब है कि आप ग्राहक के लिए विकल्प बंद कर रहे हैं। यह वास्तव में हो सकता है, केवल 3 वर्षों में वेबएप्स काम करते हैं, हमने ORMs

— अल्फ़ाब्रावो

यदि आप स्मृति डेटाबेस में परीक्षण चलाना चाहते हैं तो आपको यह उपयोगी लग सकता है

— कार्लोस पराग

यह संभव है कि एक ही सॉफ्टवेयर के कई उदाहरण विभिन्न डेटाबेस का उपयोग कर सकते हैं। लेकिन वास्तव में मौजूदा डेटा को एक DB सॉफ्टवेयर से दूसरे में ले जाना वास्तव में शायद ही कभी होता है। और जब ऐसा होता है, तो कई ओआरएम वास्तव में आपकी सहायता नहीं करते हैं।

— jlh

Answer 7

ताकि आपका ऑब्जेक्ट मॉडल और दृढ़ता मॉडल मैच हो।

Comments

हो सकता है कि आपकी दृढ़ता आपके ऑब्जेक्ट मॉडल के लिए पारदर्शी हो

— S.Lott

Answer 8

विकास खुशी, आईएमओ। ORM एब्सट्रैक्ट बहुत सारे नंगे-धातु के सामान जो आपको SQL में करना है। यह आपके कोड आधार को सरल रखता है: प्रबंधन और स्कीमा परिवर्तन के लिए कम स्रोत फ़ाइलों को घंटों के रखरखाव की आवश्यकता नहीं होती है।

मैं वर्तमान में ORM का उपयोग कर रहा हूं और इसने मेरे विकास को गति दी है।

Answer 9

सरल एसक्यूएल प्रश्नों के दोहराव को कम करने के लिए।

Answer 10

इसका कारण जो मैं देख रहा हूं, वह वीएस 200 के डीएएल टूल्स (स्कीमा मैपिंग, टेबल एडेप्टर) से उत्पन्न कोड से बचने के लिए है।

DAL / BLL मैं एक साल पहले बनाया गया था, ठीक काम कर रहा था (इसके लिए मैंने इसे बनाया था) जब तक कि किसी और ने इसका उपयोग कुछ उत्पन्न कार्यों का लाभ उठाने के लिए शुरू नहीं किया (जो मुझे पता नहीं था)

ऐसा लगता है कि यह http://wwww.asp.net से DAL / BLL समाधान की तुलना में बहुत अधिक सहज और क्लीनर समाधान प्रदान करेगा

मैं अपने खुद के SQL कमांड C # DAL कोड जनरेटर के बारे में सोच रहा था, लेकिन ORM अधिक सुरुचिपूर्ण समाधान की तरह दिखता है

Answer 11

प्रश्नों का संकलन और परीक्षण।

ओआरएम में सुधार के लिए टूलिंग के रूप में, संकलन समय त्रुटियों और परीक्षणों के माध्यम से अपने प्रश्नों की शुद्धता को तेजी से निर्धारित करना आसान है।

आपके प्रश्नों को संकलित करने से डेवलपर्स को तेज़ी से त्रुटियों को खोजने में मदद मिलती है। सही? सही। यह संकलन संभव है क्योंकि डेवलपर्स अब एसक्यूएल या एसक्यूएल के कथनों के बजाय अपने व्यापारिक वस्तुओं या मॉडल का उपयोग करके कोड में प्रश्न लिख रहे हैं।

यदि .NET में सही डेटा एक्सेस पैटर्न का उपयोग किया जाता है, तो मेमोरी कलेक्शंस के विरुद्ध अपने क्वेरी लॉजिक को यूनिट करना आसान होता है। यह आपके परीक्षणों के निष्पादन को गति देता है क्योंकि आपको डेटाबेस तक पहुंचने की आवश्यकता नहीं है, डेटाबेस में डेटा सेट करें या यहां तक ​​कि एक पूर्ण डेटा संदर्भ को स्पिन करें। [संपादित करें] यह उतना सच नहीं है जितना मैंने सोचा था कि यह इकाई के रूप में था। स्मृति में परीक्षण कठिन चुनौतियों को दूर कर सकता है। लेकिन मुझे अभी भी पिछले वर्षों की तुलना में इन एकीकरण परीक्षणों को लिखना आसान लगता है। [/ EDIT]

यह निश्चित रूप से कुछ साल पहले की तुलना में आज अधिक प्रासंगिक है जब सवाल पूछा गया था, लेकिन यह केवल विजुअल स्टूडियो और एंटिटी फ्रेमवर्क के लिए मामला हो सकता है जहां मेरा अनुभव निहित है। यदि संभव हो तो अपने स्वयं के वातावरण को प्लग इन करें।

Answer 12

एसक्यूएल को 95% समय से दूर करें ताकि टीम के सभी लोगों को यह पता न चले कि सुपर कुशल डेटाबेस विशिष्ट प्रश्नों को कैसे लिखना है।

Answer 13

मुझे लगता है कि यहां बहुत सारे अच्छे बिंदु हैं (पोर्टेबिलिटी, विकास में आसानी / रखरखाव, ओओ बिजनेस मॉडलिंग आदि पर ध्यान देना), लेकिन जब अपने ग्राहक या प्रबंधन को समझाने की कोशिश करते हैं, तो यह सब उबलता है कि आप कितने पैसे बचाएंगे एक ORM ।

विशिष्ट कार्यों के लिए कुछ अनुमान (या यहां तक ​​कि बड़ी परियोजनाएं जो आ रही हैं) कर सकते हैं और आपको (उम्मीद!) स्विच करने के लिए कुछ तर्क मिलते हैं जिन्हें अनदेखा करना मुश्किल है।

Answer 14

कोड स्मिट टेम्प्लेट का उपयोग करते हुए .net टीयर

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

क्यों कोड है कि कुछ भी उत्पन्न किया जा सकता है।

Comments

ओह। हमने एक बड़े वाणिज्यिक प्रोजेक्ट पर नेट टियर्स का उपयोग किया है, और मैं इसका उपयोग करने के खिलाफ अत्यधिक सलाह दूंगा। समस्या यह है कि यह रचना नहीं है। फू और बार वस्तुओं को क्वेरी करना चाहते हैं? आप जॉइन नहीं लिख सकते, आपको प्रत्येक ऑब्जेक्ट के लिए अलग-अलग क्वेश्चन जारी करने होंगे जो आप चाहते हैं। इसके परिणामस्वरूप डेटाबेस में बहुत सारी कॉल होती हैं, जो प्रदर्शन और परमाणुता को तोड़ सकती हैं। बुरा बुरा बुरा। दूर रहो।

— यहूदा गैब्रियल हिमंगो

Answer 15

उन्हें बताएं कि बदलाव आने पर आपके पास कितना समय / पैसा बच जाएगा और आपको अपने SQL को फिर से लिखना नहीं पड़ेगा क्योंकि ORM टूल आपके लिए ऐसा करेगा।

Answer 16

मुझे लगता है कि एक आम बात यह है कि ORM को आपके POJO में कुछ अपडेशन की आवश्यकता होगी। मुख्य रूप से स्कीमा, संबंध और क्वेरी से संबंधित है। ऐसा परिदृश्य जहां आप मॉडल ऑब्जेक्ट में परिवर्तन करने के लिए नहीं मान रहे हैं, हो सकता है क्योंकि यह प्रोजेक्ट या b / w क्लाइंट और सर्वर पर अधिक साझा किया गया हो। तो ऐसे मामलों में आपको इसे दो स्तरों में विभाजित करने की आवश्यकता होगी, जिसके लिए अतिरिक्त प्रयासों की आवश्यकता होगी।

मैं एक Android डेवलपर हूं और जैसा कि आप जानते हैं कि मोबाइल एप्लिकेशन आमतौर पर आकार में विशाल नहीं होते हैं, इसलिए शुद्ध-मॉडल और ऑरम-प्रभावित-मॉडल को अलग करने का यह अतिरिक्त प्रयास पूर्ण नहीं लगता है।

मैं समझता हूं कि प्रश्न सामान्य है। लेकिन मोबाइल ऐप्स जेनेरिक छतरी के अंदर भी आते हैं।