रूढ़िवादी बैकएंड

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

उन सभी के लिए समर्पित है जो सुंदरता के बिना प्रोग्रामिंग नहीं सोचते हैं और बेतुकेपन के बीच सुंदरता को स्वीकार नहीं करते हैं।

डोमेन मॉडल

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

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



फिर, एक नियम के रूप में, हम मॉडल को इसके कार्यान्वयन के साधनों पर प्रोजेक्ट करना शुरू करते हैं - एक प्रोग्रामिंग भाषा, एक ऑब्जेक्ट-रिलेशनल कन्वर्टर (ऑब्जेक्ट-रिलेशनल मैपर, ORM), या किसी प्रकार के जटिल ढांचे जैसे ASP.NET MVC या रूबी रेल्स पर, दूसरे शब्दों में - कोड लिखना शुरू करें। इस मामले में, हम ढांचे के पथ का अनुसरण करते हैं, जो मुझे लगता है कि मॉडल के आधार पर विकास के ढांचे में सही नहीं है, चाहे वह शुरू में कितना सुविधाजनक लगे। यहां आप एक बड़ी धारणा बनाते हैं, जो बाद में डोमेन-आधारित विकास के लाभों को नकार देता है। एक स्वतंत्र विकल्प के रूप में, किसी भी उपकरण के दायरे से सीमित नहीं है, मैं किसी विषय क्षेत्र के ऑब्जेक्ट मॉडल के निर्माण के लिए एक प्रोग्रामिंग भाषा के केवल सिंथैटिक टूल के उपयोग पर रहने का सुझाव दूंगा। अपने काम में मैं कई प्रोग्रामिंग भाषाओं का उपयोग करता हूं - सी #, जावास्क्रिप्ट, रूबी। भाग्य ने फैसला किया है कि जावा और सी # पारिस्थितिक तंत्र मेरी प्रेरणा हैं, जेएस मेरी मुख्य आय है, और रूबी मुझे पसंद है। इसलिए, मैं रूबी में सरल उदाहरण दिखाना जारी रखूंगा: मुझे विश्वास है कि इससे डेवलपर्स के लिए अन्य भाषाओं में समझने में समस्या नहीं होगी। तो, मॉडल को रूबी में इनवॉइस क्लास में पोर्ट करें:

class Invoice attr_reader :amount, :date, :created_at, :paid_at def initialize(attrs, payment_service) @created_at = DateTime.now @paid_at = nil @amount = attrs[:amount] @date = attrs[:date] @subscription = attrs[:subscription] @payment_service = payment_service end def pay credit_card = @subscription.customer.credit_card amount = @subscription.plan.price @payment_service.charge(credit_card, amount) @paid_at = DateTime.now end end 

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

 RSpec.describe Invoice do before :each do @payment_service = double(:payment_service) allow(@payment_service).to receive(:charge) @amount = 100 @credit_card = CreditCard.new({...}) @customer = Customer.new({credit_card: @credit_card, ...}) @subscription = Subscription.new({customer: customer, ...}) @invoice = Invoice.new({amount: @amount, date: DateTime.now, @subscription: subscription}, payment_service) end describe 'pay' do it "charges customer's credit card" do expect(@payment_service).to receive(:charge).with(@credit_card, @amount) @invoice.pay end it 'makes the invoice paid' do expect(@invoice.paid_at).not_to be_nil @invoice.pay end end end 

या दुभाषिया में मॉडल के साथ खेलते हैं (रूबी के लिए irb), जो अच्छी तरह से हो सकता है, हालांकि बहुत अनुकूल नहीं है, उपयोगकर्ता:

 irb > invoice = Invoice.new({amount: @amount, date: DateTime.now, @subscription: subscription}, payment_service) irb > invoice.pay 

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

 #  class User < Entity #     table :users #     # mapping  field :name, type: 'String' #   def save ... end end user = User.load(id) #     user.save #     

 #  class User #   ,      attr_accessor :name, :lastname end user = repo.load(id) #     repo.save(user) #     

यह दृष्टिकोण मूलभूत कारणों के कारण भी है - एकमात्र जिम्मेदारी के सिद्धांत का अनुपालन (एकल जिम्मेदारी सिद्धांत, एसओएलआईडी में)। यदि मॉडल, इसके कार्यात्मक घटक के अलावा, राज्य संरक्षण मापदंडों का वर्णन करता है और इसके संरक्षण और लोडिंग से भी संबंधित है, तो जाहिर है कि इसकी बहुत अधिक जिम्मेदारियां हैं। पर्सिस्टेंस इग्नोरेंस के परिणामस्वरूप और अंतिम लाभ स्टोरेज टूल को बदलने की क्षमता नहीं है और यहां तक ​​कि विकास की प्रक्रिया के दौरान भंडारण के प्रकार भी।

मॉडल-व्यू-नियंत्रक

एमवीसी अवधारणा विभिन्न सर्वरों, न केवल विभिन्न भाषाओं और प्लेटफार्मों में अनुप्रयोगों के विकास के वातावरण में इतनी लोकप्रिय है कि हम अब इस बारे में नहीं सोचते हैं कि यह क्या है और इसकी आवश्यकता क्यों है। मुझे इस संक्षिप्त नाम से सबसे अधिक सवाल हैं जिन्हें "नियंत्रक" कहा जाता है। कोड की संरचना को व्यवस्थित करने के दृष्टिकोण से, मॉडल पर समूह क्रियाओं के लिए यह एक अच्छी बात है। लेकिन नियंत्रक को एक वर्ग नहीं होना चाहिए, यह एक मॉड्यूल होना चाहिए जिसमें मॉडल तक पहुंचने के तरीके शामिल हैं। इतना ही नहीं, क्या उसके पास बिल्कुल जगह होनी चाहिए? एक डेवलपर के रूप में जिसने .NET -> रूबी -> Node.js के पथ का अनुसरण किया, मुझे बस JS (ES5) नियंत्रकों द्वारा छुआ गया था जो एक्सप्रेस के ढांचे के भीतर लागू होते हैं। अधिक कार्यात्मक शैली में नियंत्रकों को सौंपे गए कार्य को हल करने की क्षमता होने के नाते, डेवलपर्स, जैसा कि विचाराधीन है, जादू को "नियंत्रक" बार-बार लिखें। एक विशिष्ट नियंत्रक खराब क्यों है?

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

 class InvoiceController def initialize(invoice_repository, notification_service) @repository = invoice_repository @notification_service = notification_service end def index @repository.get_all end def show(id) @repository.get_by_id(id) end def create(data) @repository.create(data) @notification_service.notify_accountant end end 

यहां विचार को मॉडल के साथ अलग-अलग कक्षाओं में काम करने के तरीकों में विभाजित किया जाना है, और क्यों नहीं?

 class ListInvoices def initialize(invoice_repository) @repository = invoice_repository end def call @repository.get_all end end class CreateInvoice def initialize(invoice_repository, notification_service) @repository = invoice_repository @notification_service = notification_service end def call @repository.create(data) @notification_service.notify_accountant end end 

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

 `HTTP GET /invoices -> return all invoices` `HTTP POST /invoices -> create new invoice` 

या कम से कम

 `HTTP GET /invoices -> ./invoices/list_invoices` `HTTP POST /invoices -> ./invoices/create` 

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

निर्भरता इंजेक्शन

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



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

 class Repository; end #  (   ) class A def initialize @repo = Repository.new end end #  (   ) class A def initialize(repo) @repo = repo end end 

यह दृष्टिकोण उन लोगों की बहुत मदद करता है जो टेस्ट-ड्रिवेन डेवलपमेंट का उपयोग करते हैं। उपरोक्त उदाहरण में, हम आसानी से वस्तु के मॉडल को "हैकिंग" किए बिना, इसके इंटरफेस के अनुरूप वास्तविक रिपॉजिटरी ऑब्जेक्ट के बजाय कंस्ट्रक्टर में एक स्टब डाल सकते हैं। यह केवल DI बोनस नहीं है: जब सही तरीके से लागू किया जाता है, तो यह दृष्टिकोण आपके आवेदन में बहुत सुखद जादू लाएगा, लेकिन पहले चीजें पहले। डिपेंडेंसी इंजेक्शन एक दृष्टिकोण है जो आपको डिपेंडेंसी इनवर्जन तकनीक को एक पूर्ण वास्तु समाधान में एकीकृत करने की अनुमति देता है। कार्यान्वयन उपकरण आमतौर पर एक IoC- (नियंत्रण का उलटा) कंटेनर होता है। जावा और .NET दुनिया में वास्तव में शांत IoC कंटेनर के टन हैं, उनमें से दर्जनों हैं। जेएस और रूबी में, दुर्भाग्य से, मेरे लिए कोई उपयुक्त विकल्प नहीं हैं। विशेष रूप से, मैंने ड्राई-कंटेनर ( ड्राई-कंटेनर ) को देखा। यह वही होगा जो मेरी कक्षा का उपयोग करने जैसा लगेगा:

 class Invoice include Import['payment_service'] def pay credit_card = @subscription.customer.credit_card amount = @subscription.plan.price @payment_service.charge(credit_card, amount) end end 

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

किसी मॉडल को सहेजना और लोड करना

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

 entity Invoice do field :amount field :date field :start_date field :end_date field :created_at field :updated_at reference :user, type: User reference :subscription, type: Subscription end 

रिपॉजिटरी प्रकार की बाहरी वस्तु का उपयोग करने के लिए दृढ़ता अज्ञान काफी सरल है:

 repository.save(user) 

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

 user = session.load(User, id: 1) plan = session.load(Plan, id: 1) subscription = Subscription.new(user, plan) session.attach(subscription) invoice = Invoice.new(subscription) session.attach(invoice) # ... # -       if Date.today.yday == 1 subscription.comment = 'New year offer' invoice.amount /= 2 end session.flush 

परिणामस्वरूप, 4 के बजाय 2 निर्देशों को डेटाबेस में निष्पादित किया जाएगा, और दोनों को एक ही लेनदेन के भीतर निष्पादित किया जाएगा।

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

 class LoadPlan def initialize(session) @session = session end def call sql = <<~SQL SELECT p.* AS ENTITY plan FROM plans p WHERE p.id = 1 SQL @session.fetch(Plan, sql) end end 

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

यह सब एक साथ रखना

तो हमारे पास क्या है:

• हमने पता लगाया कि मॉडल को कैसे लोड और सहेजना है, हमने मॉडल के वेब डिलीवरी टूल, एक निश्चित राउटर के किसी न किसी आर्किटेक्चर को भी डिजाइन किया है;
• हम इस निष्कर्ष पर पहुंचे कि सभी तर्क जो विषय क्षेत्र का हिस्सा नहीं हैं, उन्हें नियंत्रकों और रिपॉजिटरी के बजाय क्रियाओं (क्रियाओं) में ले जाया जा सकता है;
• क्रियाओं को निर्भरता इंजेक्शन का समर्थन करना चाहिए
• सभ्य उपकरण निर्भरता इंजेक्शन लागू;
• आवश्यक ओआरएम कार्यान्वित किया जाता है।

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

 :receive .-> :before -> common/open_db_session GET -> welcome -> :respond <- show_welcome /auth -> :before -> current_user@users/load_current_user /profile -> GET -> plan@plans/load_plan \ -> :respond <- users/show_user_profile PATCH -> users/update_profile /plans -> GET -> current_plan@plans/load_current_plan \ -> plans@plans/load_plans \ -> :respond <- plans/list :catch -> common/handle_errors 

"GET / ओट / योजनाएँ" सभी उपलब्ध सदस्यता योजनाओं को प्रदर्शित करता है और वर्तमान को "हाइलाइट" करता है। निम्नलिखित होता है:

1. ", इससे पहले -> सामान्य / खुले_डीबी_ सत्र" - जेटसेट सत्र खोलना
2. / सामान्य ": इससे पहले -> current_user @ उपयोगकर्ता / load_current_user" - वर्तमान उपयोगकर्ता (टोकन द्वारा) लोड करें। परिणाम IoC कंटेनर में current_user (current_user @ अनुदेश) के रूप में लॉग किया गया है।
3. / योजना / योजना "current_plan @ योजनाएँ / load_current_plan" - वर्तमान योजना लोड करें। इसके लिए कंटेनर से @current_user का मान लिया जाता है। परिणाम IoC कंटेनर में current_plan (current_plan @ अनुदेश) के रूप में दर्ज किया गया है:
   
   

    class LoadCurrentPlan def initialize(current_user, session) @current_user = current_user @session = session end def call sql = <<~SQL SELECT p.* AS ENTITY plan FROM plans p INNER JOIN subscriptions s ON s.user_id = :user_id AND s.current = 't' WHERE p.id = :user_id LIMIT 1 SQL @session.execute(sql, user_id: @current_user.id) do |row| map(Plan, row, 'plan') end end end 

   
   
4. "योजनाएं @ योजनाएं / load_plans" - सभी उपलब्ध योजनाओं की सूची लोड करना। परिणाम IoC कंटेनर में योजनाओं (योजनाओं @ निर्देश) के रूप में पंजीकृत है।
5. ": उत्तर <- योजनाएं / सूची" - पंजीकृत व्यूबर्स्ट, उदाहरण के लिए JBuilder, प्रकार की 'योजना / सूची' को आकर्षित करता है:
   
   

    json.plans @plans do |plan| json.id plan.id json.name plan.name json.price plan.price json.active plan.id == @current_plan.id end 

   
   

@Plans और @current_plan के रूप में, पिछले चरणों में पंजीकृत मान कंटेनर से पुनर्प्राप्त किए जाते हैं। एक्शन कंस्ट्रक्टर में, सामान्य रूप से, आप जो कुछ भी चाहते हैं, या कंटेनर में पंजीकृत सब कुछ "ऑर्डर" कर सकते हैं। एक चौकस पाठक सबसे अधिक संभावना है एक सवाल होगा, लेकिन क्या "बहु-उपयोगकर्ता" मोड में ऐसे चर का अलगाव है? हाँ, यह करता है। तथ्य यह है कि हाइपो आईओसी कंटेनर में वस्तुओं के जीवनकाल को निर्धारित करने की क्षमता है, और इसके अलावा, इसे अन्य वस्तुओं के जीवनकाल के लिए बाध्य करता है। बांका के भीतर, @plans, @current_plan, @current_user जैसे चर अनुरोध ऑब्जेक्ट से बंधे हैं और अनुरोध पूरा होने के क्षण को नष्ट कर दिया जाएगा। वैसे, जेटसेट सत्र भी अनुरोध के साथ जुड़ा हुआ है - डेंडी अनुरोध पूरा होने पर इसके राज्य का एक रीसेट भी किया जाएगा। यानी प्रत्येक अनुरोध का अपना अलग संदर्भ है। हाइपो, डैंडी के पूरे जीवन चक्र पर शासन करता है, चाहे यह वाक्य नामों के शाब्दिक अनुवाद में कितना मजेदार रहा हो।

निष्कर्ष

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

निष्कर्ष

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