.Net प्लेटफ़ॉर्म पर प्रोटोकॉल बफ़र्स का उपयोग करना (भाग 2)

पहले भाग में, हम प्रोटोकॉल बफ़र्स के साथ मिले और उन्हें एक .Net अनुप्रयोग में उपयोग करने का प्रयास किया। आज हम शेष प्रश्नों पर चर्चा और उत्तर देना जारी रखेंगे। पहले की तरह, पाठक के पास बेहतर सीखने के लिए सी # भाषा और एसवीएन संस्करण नियंत्रण प्रणाली की थोड़ी कमांड होनी चाहिए। यह WCF के एक सामान्य विचार के रूप में भी चोट नहीं करता है, जैसा कि कोड का एक बहुत (फिर से) नहीं होगा, लेकिन पहले से ही इस तकनीक के संदर्भ में!

रुको, क्या हम एक मंच पर धारावाहिक दूसरे पर deserialized किया जा सकता है?

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

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

package Proto.Common;
message Task
{
optional int32 Id = 1;
optional DateTime CreatedAt = 2;
optional string CreatedBy = 3;
enum TaskPriority
{
Low = 0;
Medium = 1;
High = 2;
}
optional TaskPriority Priority = 4;
optional string Content = 5;
}

* This source code was highlighted with Source Code Highlighter .

क्योंकि उत्पन्न कोड काफी बड़ा है और मैन्युअल संपादन के लिए अभिप्रेत नहीं है, हम इसे छोड़ देंगे।

मैंने समर्थित जावास्क्रिप्ट भाषाओं की सूची में देखा, क्या यह प्रोटॉन के पक्ष में JSON को छोड़ने के लायक है?

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

ऊपर के उदाहरण के अलावा मैं प्रोटोबुफ़ का उपयोग कहां कर सकता हूं?

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

using System;
using System.Runtime.Serialization;

namespace Proto.Common
{
[DataContract]
public class Task
{
[DataMember(Order = 1)]
public int Id { get ; set ; }

[DataMember(Order = 2)]
public DateTime CreatedAt { get ; set ; }

[DataMember(Order = 3)]
public string CreatedBy { get ; set ; }

[DataMember(Order = 4)]
public TaskPriority Priority { get ; set ; }

[DataMember(Order = 5)]
public string Content { get ; set ; }
}
}

* This source code was highlighted with Source Code Highlighter .

जैसा कि आप देख सकते हैं, यह पहले के विवरण से थोड़ा अलग है। लेकिन ईमानदार होने के लिए, यह प्रोटोबोफ़ का उपयोग करने के एक उदाहरण की तरह नहीं दिखता है! सेवा अनुबंध:

using System.ServiceModel;

namespace Proto.Common
{
[ServiceContract]
public interface ITaskManager
{
[OperationContract]
Task[] GetTasks();
}
}

* This source code was highlighted with Source Code Highlighter .

फिर से प्रोटॉब का संकेत नहीं। केवल उल्लेख आप कर सकते हैं सेवा विन्यास फाइल है:

<? xml version ="1.0" ? >
< configuration >
< system.serviceModel >
< services >
< service name ="Proto.Server.TaskManager"
behaviorConfiguration ="Proto.Server.ServiceBehavior" >
<!-- Service Endpoints -->
< endpoint name ="Proto.Server.Endpoint"
address ="net.tcp:\\localhost:9000"
binding ="netTcpBinding"
contract ="Proto.Common.ITaskManager"
behaviorConfiguration ="Proto.Common.EndpointBehavior" />
</ service >
</ services >
< behaviors >
< serviceBehaviors >
< behavior name ="Proto.Server.ServiceBehavior" >
<!-- To receive exception details in faults for debugging purposes, set the value below to true.
Set to false before deployment to avoid disclosing exception information -->
< serviceDebug includeExceptionDetailInFaults ="true" />
</ behavior >
</ serviceBehaviors >
< endpointBehaviors >
< behavior name ="Proto.Common.EndpointBehavior" >
< protobuf />
</ behavior >
</ endpointBehaviors >
</ behaviors >
< extensions >
< behaviorExtensions >
< add name ="protobuf"
type ="ProtoBuf.ServiceModel.ProtoBehaviorExtension, protobuf-net, Version=1.0.0.280, Culture=neutral, PublicKeyToken=257b51d87d2e4d67" />
</ behaviorExtensions >
</ extensions >
</ system.serviceModel >
</ configuration >

* This source code was highlighted with Source Code Highlighter .

और ग्राहक:

<? xml version ="1.0" ? >
< configuration >
< system.serviceModel >
< client >
< endpoint name ="Proto.Client.Endpoint"
address ="net.tcp:\\localhost:9000"
binding ="netTcpBinding"
contract ="Proto.Common.ITaskManager"
behaviorConfiguration ="Proto.Common.EndpointBehavior" />
</ client >
< behaviors >
< endpointBehaviors >
< behavior name ="Proto.Common.EndpointBehavior" >
< protobuf />
</ behavior >
</ endpointBehaviors >
</ behaviors >
< extensions >
< behaviorExtensions >
< add name ="protobuf"
type ="ProtoBuf.ServiceModel.ProtoBehaviorExtension, protobuf-net, Version=1.0.0.280, Culture=neutral, PublicKeyToken=257b51d87d2e4d67" />
</ behaviorExtensions >
</ extensions >
</ system.serviceModel >
</ configuration >

* This source code was highlighted with Source Code Highlighter .

ग्राहक और सेवा का कार्यान्वयन तुच्छ है और ब्याज का नहीं।

यदि आप संदेश लॉगिंग को सक्षम करते हैं, तो आप निम्न लॉग प्रविष्टि देख सकते हैं:

< MessageLogTraceRecord Time ="2011-05-12T16:17:03.2780000+04:00" Source ="TransportSend" Type ="System.ServiceModel.Dispatcher.OperationFormatter+OperationFormatterMessage" xmlns ="http://schemas.microsoft.com/2004/06/ServiceModel/Management/MessageTrace" >
< s:Envelope xmlns:s ="http://www.w3.org/2003/05/soap-envelope" xmlns:a ="http://www.w3.org/2005/08/addressing" >
< s:Header >
< a:Action s:mustUnderstand ="1" >
tempuri.org/ITaskManager/GetTasksResponse
</ a:Action >
< a:RelatesTo >
urn:uuid:768e2f40-612c-4593-8cfb-eacb7b291a9c
</ a:RelatesTo >
< a:To s:mustUnderstand ="1" >
www.w3.org/2005/08/addressing/anonymous
</ a:To >
</ s:Header >
< s:Body >
< GetTasksResponse xmlns ="http://tempuri.org/" >
< proto >
Ci4IARIJCPTs+c/8SxAEGgpTdGV2ZSBKb2JzIAIqEUludmVudCBuZXcgaVBob25lCi8IAhIJCPTclY/4SxAEGg1TdGV2ZSBCYWxsbWVyKhFJbnN0YWxsIG93biBTa3lwZQ==
</ proto >
</ GetTasksResponse >
</ s:Body >
</ s:Envelope >
</ MessageLogTraceRecord >

* This source code was highlighted with Source Code Highlighter .

जहां तक ​​मुझे याद है - डेटा कॉन्ट्रैक्ट्स का उपयोग केवल विशेषताओं तक सीमित नहीं है, इन अनुबंधों के विस्तार के साथ चीजें कैसी हैं?

जैसे WCF में होता है। आपको पता है कि आप IExtensibleDataObject के साथ अनुबंध परिवर्तन के लिए जिम्मेदार हो सकते हैं । Protobuf-net में एक समान इंटरफ़ेस है और इसे IExtensible कहा जाता है। अंतर इतना बड़ा नहीं है, इसलिए आप इसे खुद यहां देख सकते हैं ।

क्यों कई डेवलपर्स WCF में प्रोटोबॉफ-नेट का उपयोग करने से इनकार करते हैं?

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

आपने मुझे मना लिया। मैं निश्चित रूप से अगले प्रोजेक्ट में प्रोटोबॉफ-नेट की कोशिश करूंगा। चर्चा के लिए धन्यवाद!

कृपया। परियोजना सक्रिय रूप से विकसित हो रही है, इसलिए शायद हम एक से अधिक बार इस पर चर्चा करेंगे।