জিবিডব্লিউটি-আরপিসি বনাম রিকোয়েস্টফ্যাক্টরি কখন ব্যবহার করা উচিত?


87

আমি আমার জিডব্লিউটি-আরপিসি কলগুলি নতুন জিডব্লিউটি 2.1 রিকোয়েস্টফ্যাক্টরি কলগুলিতে স্থানান্তর করতে হবে কিনা তা জানার চেষ্টা করছি।

গুগল ডকুমেন্টেশন অস্পষ্টভাবে উল্লেখ করেছে যে অনুরোধফ্যাক্টরি "ডেটা ওরিয়েন্টেড পরিষেবাদি" এর জন্য আরও ভাল ক্লায়েন্ট-সার্ভার যোগাযোগের পদ্ধতি

ডকুমেন্টেশন থেকে আমি যে বিষয়টি ছড়িয়ে দিতে পারি তা হ'ল একটি নতুন প্রক্সি শ্রেণি রয়েছে যা যোগাযোগকে সহজ করে তোলে (আপনি প্রকৃত সত্তাটি কিন্তু কেবলমাত্র প্রক্সিটিই পাস করেন না, তাই এটি হালকা ওজন এবং পরিচালনা করা সহজ)

পুরো পয়েন্টটি নাকি আমি বড় ছবিতে অন্য কিছু মিস করছি?


8
হ্যাঁ, এই প্রশ্নটি সরকারী সংস্থা ডাব্লুগাইডের সাথে যুক্ত !
törzsmókus

উত্তর:


73

জিডব্লিউটি আরপিসি এবং রিকোয়েস্টফ্যাক্টির মধ্যে বড় পার্থক্যটি হ'ল আরপিসি সিস্টেমটি "আরপিসি-বাই-কংক্রিট-টাইপ" হয় যখন অনুরোধফ্যাক্টরিটি "আরপিসি-বাই-ইন্টারফেস" হয়।

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

বেমানান কোডটির ব্যবহার পেতে, অনেক ব্যবহারকারীর PersonDTOএমন একটি পিয়ার তৈরি Personকরে যা সার্ভারে ব্যবহৃত আসল বস্তুর ছায়া দেয় । PersonDTOশুধু getters এবং setters সার্ভার সাইড এর, "ডোমেইন", একটি উপসেট রয়েছে Personঅবজেক্ট। এখন আপনাকে এমন কোড লিখতে হবে যা আপনি ক্লায়েন্টের কাছে যেতে চান এমন Personএবং PersonDTOঅবজেক্ট এবং অন্যান্য সমস্ত অবজেক্টের মধ্যে ডেটা মার্শাল করে ।

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

রিকোয়েস্টফ্যাক্টরির সাহায্যে আপনি জিডাব্লুটি আরপিসি সহজে সমর্থন করে তার চেয়ে আরও জটিল সিস্টেমের জন্য একটি আপ-ফ্রন্ট স্টার্টআপ ব্যয় প্রদান করে। অনুরোধফ্যাক্টরির উদাহরণগুলি যুক্ত করে এর ServiceLayerআচরণটি কাস্টমাইজ করতে উল্লেখযোগ্যভাবে আরও হুক সরবরাহ করে ServiceLayerDecorator


রিকোয়েস্টফ্যাক্টরিতে স্যুইচ করার আমার সিদ্ধান্তকে সমর্থন করার এটি একটি ভাল কারণ। ধন্যবাদ, বব! এটি উপলব্ধি করে এবং আমি বুঝতে পারি না কেন কিছু লোক "আপনার প্রয়োজনের ভিত্তিতে কিছু ক্ষেত্রে আরপিসি এবং অন্যগুলিতে আরএফ ব্যবহার করেন" বলে মনে হয় কারণ আরপিসির সাথে মনে হয় আপনাকে প্রচুর আঠালো কোড এবং সেই ডিটিও স্তরটি লিখতে হবে
ড্যান এল।

4
রিকোয়েস্টফ্যাক্টরির আর একটি প্লাস হ'ল এটি একই কোড সহ অ্যান্ড্রয়েড এবং জিডব্লিউটি ব্যবহার করা যেতে পারে।
প্যাট্রিক

28

আমি আরপিসি থেকে আরএফতে রূপান্তরিত হয়েছি। প্রথমে আমাকে বলতে হবে যে আমার অভিজ্ঞতাটি এতে সীমাবদ্ধ, আমি 0 হিসাবে অনেক এনটিটিপ্রক্সি ব্যবহার করেছি।

জিডব্লিউটি আরপিসির সুবিধা:

  • এটি সেট আপ করা, বুঝতে এবং শিখতে খুব সহজ!
  • ক্লায়েন্ট এবং সার্ভারে একই শ্রেণিভিত্তিক অবজেক্ট ব্যবহার করা হয়।
  • এই পদ্ধতির ফলে প্রচুর কোড সাশ্রয় হয়।
  • আদর্শ, যখন একই মডেল অবজেক্টগুলি (এবং POJOS) ক্লায়েন্ট এবং সার্ভার উভয় ক্ষেত্রেই ব্যবহৃত হয়, POJOs == মডেল ওবিজেট == ডিটিও
  • সার্ভার থেকে ক্লায়েন্টে স্টাফ সরানো সহজ।
  • ক্লায়েন্ট এবং সার্ভারের মধ্যে সাধারণ যুক্তির প্রয়োগ ভাগ করে নেওয়া সহজ (আপনার যখন অন্য যুক্তির প্রয়োজন হয় তখন এটি একটি গুরুতর অসুবিধা হিসাবে দেখা দিতে পারে)।

জিডব্লিউটি আরপিসির বিযুক্তি:

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

অনুরোধ কারখানার অসুবিধা:

  • সরকারী দস্তাবেজ থেকে সত্যিই বোঝার জন্য এটির যোগ্যতা কী! এটি সম্পূর্ণ বিভ্রান্তিকর শব্দ প্রক্সি থেকে শুরু হয় - এগুলি আসলে আরএফের ডিটিও যা স্বয়ংক্রিয়ভাবে আরএফ দ্বারা তৈরি করা হয়। প্রক্সিগুলি ইন্টারফেস দ্বারা সংজ্ঞায়িত করা হয়, যেমন @ প্রক্সিফোর্ড (জার্নাল.ক্লাস)। IDE জার্নালে সম্পর্কিত পদ্ধতি আছে কিনা তা পরীক্ষা করে দেখায়। ম্যাপিংয়ের জন্য অনেক কিছু।
  • আরএফ ক্লায়েন্ট এবং সার্ভারের সাধারণতার ক্ষেত্রে আপনার পক্ষে বেশি কিছু করবে না কারণ
  • ক্লায়েন্টে আপনাকে "PROXIES" কে আপনার ক্লায়েন্ট ডোমেন অবজেক্ট এবং তদ্বিপরীত রূপান্তর করতে হবে। এটি সম্পূর্ণ হাস্যকর। এটি কোডের কয়েকটি লাইনে বর্ণনামূলকভাবে করা যেতে পারে, তবে এটির জন্য কোনও সমর্থন নেই! কেবলমাত্র যদি আমরা আমাদের ডোমেন অবজেক্টগুলিকে আরও প্রক্সিতে ম্যাপ করতে পারি তবে জাভাস্ক্রিপ্ট পদ্ধতি JSON.stringify (.. ,,) এর মতো আরএফ টুলবক্সে মিসিং।
  • ভুলে যাবেন না যে আপনি আপনার ডোমেন অবজেক্টগুলির প্রক্সিতে স্থানান্তরযোগ্য বৈশিষ্ট্য সেট করার জন্যও দায়ী এবং তাই পুনরাবৃত্তির সাথেও।
  • সার্ভারে পোর ইরর হ্যান্ডলিং এবং - স্ট্যাক-ট্রেসগুলি সার্ভারে ডিফল্টরূপে বাদ দেওয়া হয় এবং আপনি ক্লায়েন্টে খালি অকেজো ব্যতিক্রম পাচ্ছেন। এমনকি আমি কাস্টম ত্রুটি হ্যান্ডলারটি সেট করার পরেও আমি নিম্ন-স্তরের স্ট্যাকের চিহ্নগুলি পেতে সক্ষম হইনি! ভয়ানক.
  • আইডিই সমর্থন এবং অন্য কোথাও কিছু ছোটখাটো বাগ। আমি দুটি বাগ অনুরোধ জমা দিয়েছি যা গৃহীত হয়েছিল। আইনস্টাইনের প্রয়োজন ছিল না যে এটি আসলে বাগ ছিল figure
  • ডকুমেন্টেশন সফলতা। আমি যেমন উল্লেখ করেছি যে প্রক্সিগুলি আরও ভালভাবে ব্যাখ্যা করা উচিত, শব্দটি বিভ্রান্তিকর। আমি যে সাধারণ সাধারণ সমস্যাগুলি সমাধান করছিলাম তা হ'ল ডকস ব্যবহারযোগ্য। ডিওসি থেকে ভুল বোঝাবুঝির আরেকটি উদাহরণ হ'ল জেপিএ টীকাগুলি আরএফের সাথে সংযোগ। এটি সংযুক্ত দস্তাবেজগুলি থেকে দেখায় যে তারা একসাথে খেলছে এবং হ্যাঁ, স্ট্যাক ওভারফ্লোতে একটি সম্পর্কিত প্রশ্ন রয়েছে। আমি আরএফ বোঝার আগে কোনও জেপিএ 'সংযোগ' ভুলে যাওয়ার পরামর্শ দিচ্ছি।

রিকোয়েস্টফ্যাক্টরির সুবিধা

  • দুর্দান্ত ফোরাম সমর্থন।
  • আইডিই সমর্থনটি বেশ ভাল (তবে আরপিসির বিপরীতে কোনও সুবিধা নয়)
  • আপনার ক্লায়েন্ট এবং সার্ভার বাস্তবায়নের নমনীয়তা (আলগা সংযোগ)
  • অভিনব স্টাফ, সহজ ডিটিও-এর বাইরে এন্টিপ্রক্সিতে সংযুক্ত, ক্যাশিং, আংশিক আপডেটগুলি, মোবাইলের জন্য খুব দরকারী।
  • আপনি ডিটিও-র সহজ প্রতিস্থাপন হিসাবে ভ্যালুপ্রক্সিকে ব্যবহার করতে পারেন (তবে আপনাকে নিজেরাই তাই অভিনব রূপান্তরগুলি করতে হবে না)।
  • শিম বৈধকরণ JSR-303 এর জন্য সমর্থন।

সাধারণভাবে জিডাব্লুটিটির অন্যান্য অসুবিধাগুলি বিবেচনা করে:

  • সরবরাহিত JUnit সমর্থন সহ ইন্টিগ্রেশন টেস্টগুলি (GWT ক্লায়েন্ট কোড + রিমোট সার্ভার) চালানো অসম্ভব <= সমস্ত জেএসএনআইকে উপহাস করা উচিত (যেমন লোকালস্টোরেশন), এসওপি একটি বিষয়।

  • সেটআপ পরীক্ষার জন্য কোনও সমর্থন নেই - হেডলেস ব্রাউজার + রিমোট সার্ভার <= জিডব্লিউটি, এসওপি-র জন্য কোনও সাধারণ হেডলেস পরীক্ষা নেই।

  • হ্যাঁ, সেলেনিয়াম ইন্টিগ্রেশন পরীক্ষা চালানো সম্ভব (তবে এটি আমি চাই না)

  • জেএসএনআই খুব শক্তিশালী, তবে সম্মেলনে তারা যে চকচকে আলোচনা করে তারা জেএসএনআই কোড লেখার কিছু নিয়মও রয়েছে সে বিষয়ে তেমন কথা বলে না। আবার, কীভাবে একটি সাধারণ কলব্যাক লিখতে হবে তা নির্ধারণ করা সত্যিকারের গবেষক।

সংক্ষেপে, জিপিডব্লিউটি আরপিসি থেকে রিকোয়েস্টফ্যাক্টরিতে রূপান্তর করা WIN-WIN পরিস্থিতি থেকে অনেক দূরে থাকে, যখন আরপিসি বেশিরভাগ ক্ষেত্রে আপনার প্রয়োজনের সাথে খাপ খায়। আপনি ক্লায়েন্ট ডোমেন অবজেক্ট থেকে প্রক্সি এবং বিপরীতে টন রূপান্তরগুলি লিখেছেন writing তবে আপনি নিজের সমাধানটির কিছুটা নমনীয়তা এবং দৃust়তা পাবেন। এবং ফোরামে সমর্থন দুর্দান্ত, শনিবারেও!

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


চেকআউট জেবস ইরাই। আমি আরপিসিতে তাদের দৃষ্টিভঙ্গি পছন্দ করি।
Καrτhικ

6

আমি আমার সমস্ত প্রতিষ্ঠানের জন্য প্রক্সি ক্লাস তৈরির ধারণাটি বেশ বিরক্তিকর মনে করি। আমার হাইবারনেট / জেপিএ pojos ডাটাবেস মডেল থেকে স্বয়ংক্রিয়ভাবে উত্পাদিত হয়। আরপিসির জন্য এখন আমার কেন একটি দ্বিতীয় আয়না তৈরি করা দরকার? আমাদের কাছে একটি সুন্দর "উত্সাহ" কাঠামো রয়েছে যা পোজোদের "ডি-হাইবারনেটিং" যত্ন করে।

এছাড়াও, সার্ভিস ইন্টারফেসগুলি সংজ্ঞায়িত করার ধারণা যা জাভা চুক্তি হিসাবে সার্ভার সাইড পরিষেবাটি বেশ কার্যকরভাবে প্রয়োগ করে না তবে পদ্ধতিগুলি বাস্তবায়ন করে - আমার কাছে খুব J2EE 1.x / 2.x শোনায়।


4
এটি বিরক্তিকর, তবে যদি আপনাকে যাইহোক প্রক্সি তৈরি করতে হয়, তবে আরেএফ those প্রক্সিগুলি পরিচালনার জন্য আপনাকে যে অতিরিক্ত সহায়তা দেয় তা বরং আপনি চাইতেন। প্রত্যেকে ক্লায়েন্টকে পুরো পোজো পাঠাতে চায় না - উদাহরণস্বরূপ, একটি জুজু খেলা বিবেচনা করুন - আপনার প্লেয়ার অবজেক্টে এমন তথ্য থাকতে পারে যা প্রত্যেকের হাতে দেখা উচিত (হাতে থাকা কার্ডের সংখ্যা, মুখগুলি দেখানো কার্ডগুলি, মোট চিপস) এবং অন্যান্য তথ্য যা কেবলমাত্র একজন খেলোয়াড়কে দেখতে হবে (কার্ডগুলির মুখোমুখি)।
পিটার পুনরুদ্ধার করুন

আপনার পোকার উদাহরণটি বৈধ - আমরা আমাদের "এসটিভিশন" কাঠামোটি মূল্যবোধ দমন করতে ব্যবহার করে এমন টীকাগুলি (@ ওয়্যারট্রান্সিয়েন্ট) থাকার মাধ্যমে আমরা এটিকে ঘিরে কাজ করি।
Καrτhικ

4

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

"সাধারণ ক্লায়েন্ট / সার্ভার স্থাপনা

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

মাল্টি-টিয়ার মোতায়েন

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

এছাড়াও নোট করুন যে একটি একক রিকুয়েস্টফ্যাকারি পরিষেবা স্থাপনের জন্য প্রায় or টি বা আরও বেশি জাভা ক্লাস তৈরি করা দরকার যেখানে আরপিসি হিসাবে কেবল ৩ টির প্রয়োজন = আমার কোডটিতে আরও কোড == আরও ত্রুটি এবং জটিলতা।

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

আমি এটিও বিশ্বাস করি না যে অনুরোধফ্যাক্টরি পরিষেবাগুলি আরপিসি পরিষেবার মতো সিরিয়ালাইজেশন।

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

আমার মতে সেরা আর্কিটেকচারটি দুটি ওয়েব অ্যাপ্লিকেশন, একটি ক্লায়েন্ট এবং একটি সার্ভার ব্যবহার করা। সার্ভারটি হ'ল একটি সাধারণ লাইটওয়েট জেনেরিক জাভা ওয়েব অ্যাপ্লিকেশন যা সার্লেটলেট jar লাইব্রেরি ব্যবহার করে। ক্লায়েন্টটি জিডব্লিউটি T আপনি ক্লায়েন্ট ওয়েব অ্যাপ্লিকেশনটির সার্ভার সাইডে জিডব্লিউটি-আরপিসির মাধ্যমে বিশ্রামের অনুরোধ জানান। ক্লায়েন্টটির সার্ভার সাইডটি কেবলমাত্র একটি পাস যদিও এইচটিএমএপি ক্লায়েন্টকে অ্যাপাচি করে যা আপনি আপনার সার্ভার সার্লেট ওয়েব অ্যাপ্লিকেশনটিতে একক সার্ভলেট হিসাবে চলমান অনুরোধ হ্যান্ডলারের মধ্যে একটি ধৈর্যশীল টানেল ব্যবহার করেন। সার্লেট ওয়েব অ্যাপ্লিকেশনটিতে আপনার ডাটাবেস অ্যাপ্লিকেশন স্তর থাকা উচিত (হাইবারনেট, কেয়েন, এসকিউএল ইত্যাদি।) এটি আপনাকে সত্যিকারের ক্লায়েন্টের থেকে ডেটাবেস অবজেক্ট মডেলগুলিকে পুরোপুরি বিবাহবিচ্ছেদের অনুমতি দেয় যা আপনার অ্যাপ্লিকেশন বিকাশ এবং ইউনিট পরীক্ষার আরও অনেক বেশি এক্সটেনসিবল এবং মজবুত উপায় সরবরাহ করে। অনুমোদিত এটির জন্য প্রাথমিক সেটআপ সময়টি অল্প সময়ের দরকার হয়, তবে শেষ পর্যন্ত আপনাকে GWT এর বাইরে বসে একটি গতিশীল অনুরোধ কারখানা তৈরি করতে দেয়। এটি আপনাকে উভয় বিশ্বের সেরা লাভ করতে সহায়তা করে। Gwt ক্লায়েন্টকে সংকলিত বা বিল্ড না করে পরীক্ষা করতে এবং আপনার সার্ভারে পরিবর্তন করতে সক্ষম হওয়ার কথা নয়।


0

আমি মনে করি এটি ক্লায়েন্টের পক্ষে ভারী পোজো থাকলে উদাহরণস্বরূপ সহায়ক, যদি আপনি হাইবারনেট বা জেপিএ সত্তা ব্যবহার করেন। খুব হালকা সত্তা সহ একটি জ্যাঙ্গো স্টাইলের অধ্যবসায় কাঠামোটি ব্যবহার করে আমরা আরেকটি সমাধান গ্রহণ করেছি।


0

একমাত্র আমি যে সতর্কতা রাখব তা হ'ল অনুরোধফ্যাক্টরি বাইনারি ডেটা ট্রান্সপোর্ট (সম্ভবত ডিআরপিসি?) ব্যবহার করে এবং সাধারণ জিডব্লিউটি-আরপিসি ব্যবহার করে না।

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


4
আসলে সিঙ্কপ্রোকির মতো তৃতীয় পক্ষের সরঞ্জামের প্রয়োজন ছাড়াই অনুরোধফ্যাক্টরি বাক্সের বাইরে "খাঁটি জাভা" বাস্তবায়ন সরবরাহ করে। দেখুন stackoverflow.com/questions/4853188/...
টমাস Broyer

0

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

শ্রদ্ধা ড্যানিয়েল


আমি এই উদ্বেগগুলি ভাগ করছি ... আপনি কি আরএফের সাথে শেষ করেছেন?
এইচডিভ

0

এটি কি বলা যায় যে সীমিত এমআইএস অ্যাপ্লিকেশনটি বিবেচনা করার সময়, 10-20 ক্রুড'এল ব্যবসায়িক অবজেক্টের সাথে এবং প্রতিটিকে -10 1-10 ডলারের বৈশিষ্ট্য সহ বলুন, এটি কোন ব্যক্তিগত পথে চলেছে কোন পথে যেতে হবে?

যদি তা হয় তবে সম্ভবত আপনার অ্যাপ্লিকেশনটি কীভাবে স্কেল হয়ে যাচ্ছে তা আপনার রুট GWT RPC বা রিকোয়েস্টফ্যাক্টিকে বেছে নেওয়ার মূল বিষয় হতে পারে:

  1. আমার অ্যাপ্লিকেশনটি অপেক্ষাকৃত সীমিত সংখ্যক সংস্থার সাথে থাকার প্রত্যাশা করলেও তাদের সংখ্যার দিক থেকে ব্যাপকভাবে বৃদ্ধি পাবে। 10-20 অবজেক্টস * 100,000 রেকর্ড।

  2. আমার অ্যাপ্লিকেশন সত্তাগুলির প্রস্থে উল্লেখযোগ্যভাবে বৃদ্ধি পেতে চলেছে তবে প্রত্যেকটির সাথে জড়িত আপেক্ষিক সংখ্যা কম থাকবে। 5000 টি অবজেক্ট * 100 রেকর্ড

  3. আমার অ্যাপ্লিকেশনটি অপেক্ষাকৃত সীমিত সংস্থার সাথে থাকার আশা করে এবং তুলনামূলকভাবে কম সংখ্যায় যেমন 10-20 অবজেক্ট * 100 রেকর্ড থাকবে

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.