প্রোটোবুফ ডিজাইনের নিদর্শন


19

আমি একটি জাভা ভিত্তিক পরিষেবাদির জন্য গুগল প্রোটোকল বাফারগুলি মূল্যায়ন করছি (তবে ভাষা অজ্ঞায়নের নিদর্শনগুলি আশা করছি)। আমার দুটি প্রশ্ন আছে:

প্রথমটি একটি বিস্তৃত সাধারণ প্রশ্ন:

আমরা কোন নিদর্শনগুলি ব্যবহার করতে দেখছি? শ্রেণীর সংস্থার সাথে সম্পর্কিত নিদর্শনগুলি (যেমন, ফটো ফাইল, প্যাকেজিং এবং বিতরণ প্রতি বার্তা) এবং বার্তার সংজ্ঞা (যেমন, পুনরাবৃত্তি ক্ষেত্র বনাম পুনরাবৃত্তি এনক্যাপসুলেটেড ক্ষেত্রসমূহ *) ইত্যাদি etc.

এক্সএমএলের মতো প্রতিষ্ঠিত প্রোটোকলগুলির জন্য যখন প্রচুর পরিমাণে তথ্য রয়েছে তখন গুগল প্রোটোবফ সহায়তা পৃষ্ঠাগুলি এবং সর্বজনীন ব্লগে এই ধরণের খুব সামান্য তথ্য রয়েছে।

নিম্নলিখিত দুটি ভিন্ন ধরণ সম্পর্কে আমার নির্দিষ্ট প্রশ্ন রয়েছে:

  1. ফটো ফাইলগুলিতে বার্তাগুলি উপস্থাপন করুন, সেগুলি একটি পৃথক জার হিসাবে প্যাকেজ করুন এবং সেবার গ্রাহককে লক্ষ্য করতে শিপ করুন - যা মূলত আমার ধারণা ডিফল্ট পদ্ধতির।

  2. এটি একই করুন তবে প্রত্যেকটি বার্তার চারপাশে হ্যান্ড ক্র্যাফ্টেড মোড়কের (উপ-শ্রেণি নয়!) অন্তর্ভুক্ত করুন যা অন্ততপক্ষে এই দুটি পদ্ধতি সমর্থন করে এমন একটি চুক্তি কার্যকর করে (টি হ'ল রেপার ক্লাস, ভি বার্তা শ্রেণি (জেনেরিকগুলি কিন্তু ব্রেভিটির জন্য সরলিকৃত বাক্য গঠন ব্যবহার করে) :

    public V toProtobufMessage() {
        V.Builder builder = V.newBuilder();
        for (Item item : getItemList()) {
            builder.addItem(item);
        }
        return builder.setAmountPayable(getAmountPayable()).
                       setShippingAddress(getShippingAddress()).
                       build();
    }
    
    public static T fromProtobufMessage(V message_) { 
        return new T(message_.getShippingAddress(), 
                     message_.getItemList(),
                     message_.getAmountPayable());
    }
    

(২) এর সাথে আমি দেখতে পাচ্ছি তার একটি সুবিধা হ'ল আমি প্রবর্তিত জটিলতাগুলি আড়াল করতে পারি এবং আমার মোড়কে V.newBuilder().addField().build()কিছু অর্থপূর্ণ পদ্ধতি যেমন isOpenForTrade()বা isAddressInFreeDeliveryZone()ইত্যাদি যুক্ত করতে পারি। (২) এর সাথে আমি যে দ্বিতীয় সুবিধাটি দেখতে পাচ্ছি তা হ'ল আমার ক্লায়েন্টরা অপরিবর্তনীয় বস্তুগুলির সাথে লেনদেন করে (এমন কিছু যা আমি মোড়কের ক্লাসে প্রয়োগ করতে পারি)।

(২) এর সাথে আমি দেখতে পাচ্ছি তার একটি অসুবিধা হ'ল আমি কোডটি নকল করি এবং প্রোটোগ্রাফ ফাইলগুলির সাথে আমার মোড়ক ক্লাসগুলি সমন্বয় করতে পারি।

কারও কাছে এই দুটি পদ্ধতির যে কোনও একটিতে আরও ভাল কৌশল বা আরও সমালোচনা রয়েছে?


* একটি পুনরাবৃত্তি ক্ষেত্রটি আবদ্ধ করে আমি এর অর্থ বার্তাগুলি বোঝায়:

message ItemList {
    repeated item = 1;
}

message CustomerInvoice {
    required ShippingAddress address = 1;
    required ItemList = 2;
    required double amountPayable = 3;
}

পরিবর্তে এই বার্তাগুলির পরিবর্তে:

message CustomerInvoice {
    required ShippingAddress address = 1;
    repeated Item item = 2;
    required double amountPayable = 3;
}

আমি দ্বিতীয়টি পছন্দ করি তবে এর বিরুদ্ধে যুক্তি শুনে খুশি।


নতুন ট্যাগ তৈরি করতে আমার আরও 12 টি পয়েন্ট দরকার এবং আমি মনে করি এই পোস্টের জন্য প্রোটোবফ একটি ট্যাগ হওয়া উচিত।
অপুরভ খুরসিয়া

উত্তর:


13

আমি যেখানে কাজ করি সেখানে প্রোটোবুফের ব্যবহার গোপন করার সিদ্ধান্ত নেওয়া হয়েছিল। আমরা .protoঅ্যাপ্লিকেশনগুলির মধ্যে ফাইলগুলি বিতরণ করি না , বরং যে কোনও অ্যাপ্লিকেশন যা একটি প্রোটবুফ ইন্টারফেস প্রকাশ করে তা ক্লায়েন্টের লাইব্রেরি রফতানি করে যা এর সাথে কথা বলতে পারে।

আমি কেবল এই প্রোটোবুফ-এক্সপেজিং অ্যাপ্লিকেশনগুলির মধ্যে একটিতে কাজ করেছি, তবে এতে প্রতিটি প্রোটোবুফ বার্তা ডোমেনের কিছু ধারণার সাথে মিলে যায়। প্রতিটি ধারণার জন্য, একটি সাধারণ জাভা ইন্টারফেস রয়েছে। তারপরে একটি রূপান্তরকারী শ্রেণি রয়েছে, যা একটি প্রয়োগের উদাহরণ নিতে পারে এবং একটি উপযুক্ত বার্তা অবজেক্ট তৈরি করতে পারে, এবং একটি বার্তা অবজেক্ট নিতে পারে এবং ইন্টারফেসের প্রয়োগের একটি উদাহরণ তৈরি করতে পারে (যেমনটি ঘটে, সাধারণত একটি সাধারণ বেনামে বা স্থানীয় শ্রেণীর সংজ্ঞা দেওয়া হয়) রূপান্তরকারী ভিতরে)। প্রোটোবুফ-উত্পাদিত বার্তা ক্লাস এবং রূপান্তরকারীরা একত্রে একটি লাইব্রেরি গঠন করে যা অ্যাপ্লিকেশন এবং ক্লায়েন্ট লাইব্রেরি উভয় দ্বারা ব্যবহৃত হয়; ক্লায়েন্ট লাইব্রেরি সংযোগ স্থাপন এবং বার্তা প্রেরণ এবং গ্রহণের জন্য একটি অল্প পরিমাণে কোড যুক্ত করে।

ক্লায়েন্ট অ্যাপ্লিকেশনগুলি তারপরে ক্লায়েন্ট লাইব্রেরি আমদানি করে এবং যে কোনও ইন্টারফেস তারা প্রেরণ করতে চায় তার বাস্তবায়ন সরবরাহ করে। সত্যই, উভয় পক্ষই পরেরটি কাজ করে।

স্পষ্ট করার জন্য, এর অর্থ হ'ল যদি আপনার কাছে একটি অনুরোধ-প্রতিক্রিয়া চক্র রয়েছে যেখানে ক্লায়েন্ট একটি পক্ষের আমন্ত্রণ প্রেরণ করছে এবং সার্ভারটি একটি আরএসভিপি দিয়ে প্রতিক্রিয়া জানাচ্ছে, তবে জড়িত জিনিসগুলি হ'ল:

  • পার্টিআইভেশন বার্তা, .protoফাইলটিতে লেখা
  • PartyInvitationMessage বর্গ দ্বারা উত্পাদিত protoc
  • PartyInvitation ইন্টারফেস, ভাগ লাইব্রেরি সংজ্ঞায়িত
  • ActualPartyInvitation, PartyInvitationক্লায়েন্ট অ্যাপ্লিকেশন দ্বারা সংজ্ঞায়িত একটি কংক্রিট বাস্তবায়ন (আসলে এটি বলা হয় না!)
  • StubPartyInvitation, PartyInvitationভাগ করা লাইব্রেরি দ্বারা সংজ্ঞায়িত একটি সাধারণ বাস্তবায়ন
  • PartyInvitationConverter, যা একটি রূপান্তর করতে পারেন PartyInvitationএকটি থেকে PartyInvitationMessage, এবং একটি PartyInvitationMessageএকটি থেকেStubPartyInvitation
  • আরএসভিপি বার্তা, .protoফাইলে লেখা
  • RSVPMessage বর্গ দ্বারা উত্পাদিত protoc
  • RSVP ইন্টারফেস, ভাগ লাইব্রেরি সংজ্ঞায়িত
  • ActualRSVP, RSVPসার্ভার অ্যাপ্লিকেশন দ্বারা সংজ্ঞায়িত একটি কংক্রিট বাস্তবায়ন (এটি আসলে বলা হয় না!)
  • StubRSVP, RSVPভাগ করা লাইব্রেরি দ্বারা সংজ্ঞায়িত একটি সাধারণ বাস্তবায়ন
  • RSVPConverter, যা একটি রূপান্তর করতে পারেন RSVPএকটি থেকে RSVPMessage, এবং একটি RSVPMessageএকটি থেকেStubRSVP

আমাদের পৃথক প্রকৃত এবং অনড় বাস্তবায়ন করার কারণটি হ'ল আসল বাস্তবায়নগুলি সাধারণত জেপিএ-ম্যাপযুক্ত সত্তা শ্রেণি; সার্ভার হয় তাদের তৈরি করে এবং ধরে রাখে, বা ডাটাবেস থেকে এটিকে জিজ্ঞাসা করে, তারপরে প্রেরণ করার জন্য এগুলি প্রোটোবুফ স্তরে সরিয়ে দেয়। এটি অনুভূত হয় নি যে সংযোগ গ্রহণের পক্ষে সেই শ্রেণীর উদাহরণ তৈরি করা উপযুক্ত ছিল, কারণ তারা দৃ a়তার সাথে প্রসঙ্গে আবদ্ধ হবে না। তদ্ব্যতীত, সত্ত্বাগুলি প্রায়শই তারের উপর দিয়ে সঞ্চারিত হওয়ার চেয়ে আরও বেশি ডেটা ধারণ করে, তাই এটি গ্রহণের পক্ষে অক্ষত অবজেক্ট তৈরি করাও সম্ভব হত না। আমি পুরোপুরি নিশ্চিত নই যে এটিই সঠিক পদক্ষেপ ছিল, কারণ এটি আমাদের কাছে মেসেজের প্রতি আরও একটি ক্লাস রেখে গেছে যা অন্যথায় আমাদের করা উচিত ছিল না।

প্রকৃতপক্ষে, আমি সম্পূর্ণরূপে নিশ্চিত নই যে প্রোটোবুফ ব্যবহার করা মোটেই ভাল ধারণা ছিল; যদি আমরা সরল পুরানো আরএমআই এবং সিরিয়ালাইজেশনের সাথে আটকে থাকি তবে আমাদের প্রায় প্রায় অবজেক্ট তৈরি করতে হত না। অনেক ক্ষেত্রে, আমরা কেবলমাত্র আমাদের সত্তা শ্রেণিগুলিকে সিরিয়ালাইজযোগ্য হিসাবে চিহ্নিত করতে পারি এবং এটি দিয়ে যেতে পারি।

এখন, এই সমস্ত কথা বলার পরে, আমার একটি বন্ধু যিনি গুগলে কাজ করেন, একটি কোডবেসে যা মডিউলগুলির মধ্যে যোগাযোগের জন্য প্রোটোবুফের ভারী ব্যবহার করে। তারা সম্পূর্ণ ভিন্ন পদ্ধতির গ্রহণ করে: তারা উত্পন্ন বার্তাগুলির ক্লাসগুলি মোটেও আবদ্ধ করে না এবং উত্সাহের সাথে তাদের কোডে গভীর (ইশ) দেয়। এটি একটি ভাল জিনিস হিসাবে দেখা হয়, কারণ এটি ইন্টারফেসকে নমনীয় রাখার সহজ উপায়। বার্তাগুলির বিকশিত হওয়ার সময় সিঙ্কে রাখার জন্য কোনও স্ক্যাফোল্ডিং কোড নেই, এবং উত্পন্ন ক্লাসগুলি hasFoo()সময়ের সাথে যুক্ত হওয়া ক্ষেত্রগুলির উপস্থিতি বা অনুপস্থিতি সনাক্ত করার জন্য কোড প্রাপ্ত করার জন্য প্রয়োজনীয় সমস্ত প্রয়োজনীয় পদ্ধতি সরবরাহ করে। তবে মনে রাখবেন যে গুগলে কাজ করা লোকেরা (ক) বরং চালাক এবং (খ) কিছু বাদামের হয়ে থাকে।


এক পর্যায়ে, আমি স্ট্যান্ডার্ড সিরিয়ালাইজেশনের জন্য কম-বেশি ড্রপ-ইন প্রতিস্থাপন হিসাবে JBoss সিরিয়ালাইজেশন ব্যবহার করে দেখেছি । এটি বেশ দ্রুত ছিল। প্রোটোবুফের মতো দ্রুত নয়, যদিও।
টম অ্যান্ডারসন

জ্যাকসন 2 ব্যবহার করে জেএসএন সিরিয়ালাইজেশনটি খুব দ্রুত is আমি জিবিপি সম্পর্কে যে জিনিসটি ঘৃণা করি তা হ'ল প্রধান ইন্টারফেস ক্লাসগুলির অপ্রয়োজনীয় নকল।
অপুরভ খুরসিয়া

0

অ্যান্ডারসন উত্তর যুক্ত করার জন্য চতুরতার সাথে একে অপরের মধ্যে বাসা বাঁধতে এবং এটি অত্যধিক করার জন্য একটি সূক্ষ্ম রেখা রয়েছে। সমস্যাটি হ'ল প্রতিটি বার্তা পর্দার আড়ালে এবং ডেটাগুলির জন্য সমস্ত ধরণের অ্যাকসেসর এবং হ্যান্ডলারের পিছনে একটি নতুন বর্গ তৈরি করে। তবে আপনার যদি ডেটা অনুলিপি করতে হয় বা একটি মান পরিবর্তন করতে হয় বা বার্তাগুলির তুলনা করতে হয় তবে এর জন্য একটি ব্যয় করতে হবে। আপনার কাছে প্রচুর ডেটা থাকে বা সময়মতো আবদ্ধ থাকলে এই প্রক্রিয়াগুলি খুব ধীর এবং বেদনাদায়ক করতে পারে।


2
এই আরো একটি স্পর্শিনী মন্তব্য দেখে মনে পড়লো, দেখুন উত্তর কিভাবে
মশা

1
ভাল এটি নয়: কোনও ডোমেন নেই এখানে ক্লাসগুলি রয়েছে এর সবকটি শব্দটি শেষ পর্যন্ত (ওহ আমি আমার সমস্ত বিষয় সি ++ তে বিকাশ করছি তবে এটি অবশ্যই কোনও ইস্যু নয়)
মার্কো বেনসেক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.