बीगो अब गो नहीं है

किसी भी प्रचार बहुत अजीब है जब आप इसे पक्ष से देखते हैं। जब आप सीधे इसमें शामिल होते हैं तो कम मज़ेदार होते हैं।

हाइप गो 2014 में कहीं गिर गया, जब 1000RPM (प्रति मिनट अनुरोध) वाले अनुप्रयोगों के लेखकों ने अचानक एक के रूप में फैसला किया कि उन्हें तुरंत संगामिति की आवश्यकता है, क्योंकि उनका 1000RPM 1000RPS में बदल जाने वाला था (जो कि इतना भी नहीं है। वास्तव में)।

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

रिचर्ड एंग ने अपने लेख "ए वर्ड द बीगोइस्ट" की श्रृंखला के साथ बीगो को जनता के बीच बढ़ावा देने में महत्वपूर्ण योगदान दिया। व्यावहारिक रूप से "रिचर्ड का सुसमाचार।" विडंबना यह है कि इस तथ्य के बावजूद कि रिचर्ड फ्रान्टली गो को बढ़ावा दे रहा है, वह खुद इस पर नहीं लिखता है।

बदले में, मैंने गो के साथ काम किया, और इससे भी बदतर, बीगो के साथ, मैंने बहुत काम किया। और मैं कह सकता हूं कि यह स्पष्ट रूप से गो पर विकास का तरीका नहीं है।

आइए बीगो के कुछ बुनियादी पहलुओं पर गौर करें, और क्यों वे गो और उद्योग में विभिन्न सर्वोत्तम प्रथाओं का खंडन करते हैं।

फ़ोल्डर संरचना

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

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

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

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

ORM

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

qs.Filter("profile__age__gte", 18) // WHERE profile.age >= 18 

लेकिन बीगो ओआरएम के साथ मुख्य समस्या यह भी नहीं है कि आपको मालिकाना भाषा से निपटने की आवश्यकता है, लेकिन यह कि सभी खराब गो प्रथाओं का उपयोग करता है, चाहे वह आयात संबंधी दोष हो:

 import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" ) 

या रजिस्टर मॉडल init ():

 func init(){ orm.RegisterModel(new(User)) } 

अपने आप को एक एहसान करो, भले ही आप अभी भी बीगो के साथ काम करने के लिए कुछ अकथनीय कारण के लिए निर्णय लेते हैं, बीगो ओआरएम का उपयोग न करें। अगर ORM के बिना आपका जीवन अच्छा नहीं है (और आप गो, डियर की दुनिया में क्या कर रहे हैं?), GORM का उपयोग करें। यह कम से कम समर्थित है। अन्यथा, "डेटाबेस / एसक्यूएल" आपकी मदद करेगा।

मधुमक्खी का औजार

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

स्वचालित रूटिंग

गो एक दृढ़ता से टाइप की गई भाषा है जो जेनरिक या एनोटेशन का समर्थन नहीं करती है। इस पर एमवीसी ढांचे को कैसे ढालना है? टिप्पणियों को पढ़ने और फ़ाइलों को उत्पन्न करके, बिल्कुल।

यह कुछ इस तरह दिखता है:

 // @Param body body models.Object true "The object content" // @Success 200 {string} models.Object.Id // @Failure 403 body is empty // @router / [post] func (this *ObjectController) Post() { var ob models.Object json.Unmarshal(this.Ctx.Input.RequestBody, &ob) objectid := models.AddOne(ob) this.Data["json"] = map[string]string{"ObjectId": objectid} this.ServeJson() } 

साक्ष्य, जैसा कि आप देख सकते हैं, शून्य है। पोस्ट () फ़ंक्शन कुछ भी प्राप्त या वापस नहीं करता है। http.Request? नहीं, नहीं सुना।

खैर, सभी मार्ग कैसे काम करता है? जब आप कुख्यात मधुमक्खी शुरू करते हैं, तो एक और फ़ाइल उत्पन्न होती है, commentsRouter_controllers.go, जिसमें इस तरह के अद्भुत कोड का एक उदाहरण है:

 func init() { beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"] = append(beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"], beego.ControllerComments{ Method: "Post", Router: `/`, AllowHTTPMethods: []string{"post"}, MethodParams: param.Make(), Filters: nil, Params: nil}) ... } 

देखें, प्रत्येक परिवर्तन के बाद इस फाइल को फिर से बनाना और 'कमिट' करना न भूलें। हाल तक तक, स्थिति और भी दु: खद थी, और परीक्षणों के दौरान यह फ़ाइल अपने आप उत्पन्न हो गई थी, इसलिए आपने उत्पादन में आने वाली समस्याओं के बारे में पहले ही जान लिया था। ऐसा लगता है कि हाल के संस्करणों में यह अजीब व्यवहार तय किया गया है।

घटक परीक्षण

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

और यह ऐसी ट्रिफ़ल नहीं है, क्योंकि, मुझे याद है, गो पैकेज == फ़ोल्डर में। और यदि एक ही पैकेज में स्थित परीक्षण निजी विधि को कॉल कर सकता है, तो दूसरे पैकेज में स्थित परीक्षण अब नहीं है।

लेकिन ठीक है, सब कुछ फ़ोल्डर संरचना तक सीमित होगा। बीगो कोड, सिद्धांत रूप में, परीक्षण करना बहुत मुश्किल है, क्योंकि इसमें सब कुछ एक साइड इफेक्ट है।

यह कैसे बीगो प्रश्नों रूटर्स है:

 import ( _ "github.com/../../routers" ) 

बिचौलियों के साथ एक ही कहानी, और नियंत्रकों के साथ जो मैंने पहले उल्लेख किया था।

प्रलेखन

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

अब चीनी में केवल कुछ पुल अनुरोध हैं:



और विशेष रूप से मुद्दों में:

एक निष्कर्ष के बजाय

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