মাইক্রোসার্চেসের মধ্যে ডিটিও অবজেক্টগুলি ভাগ করা


15

TL; DR - পরিষেবাগুলির মধ্যে কোনও POJO লাইব্রেরি ভাগ করা ঠিক আছে কি?

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

আমার ক্ষেত্রে - আমি এমন একটি পরিষেবা বিবেচনা করছি যা ডেটার একটি অবজেক্ট তৈরি করে। ধরা যাক এই বস্তুটি একটি পিইটি। এটি ডাটাবেস সত্তা নয়, তবে কঠোরভাবে কোনও পজো যা অন্তর্নিহিত ডেটার স্পষ্টভাবে উপস্থাপন করে। এই POJO এপিআই সংজ্ঞায়িত করেছে। ধরে নিন: পোষা - বয়স, ওজন, নাম, মালিক, ঠিকানা, প্রজাতি ইত্যাদি

পরিষেবাদি 1 - পেটকিপার: এটি যে কোনও কারণে একটি পোষা প্রাণী তৈরি করবে এবং সমস্ত ডেটা ধরে রাখবে এবং পোষা প্রাণীটি পেতে এই পরিষেবাটি উল্লেখ করতে হবে, বা পোষা প্রাণীকে পরিবর্তন করতে হবে, নাম পরিবর্তন করতে পারেন, বা ঠিকানা পরিবর্তন অবশ্যই একটি পোষকের মাধ্যমে করা উচিত এই পরিষেবাতে API কল।

পরিষেবা 2 - পেটএ্যাকসেসর: এই পরিষেবাগুলি পোষা প্রাণীর সংগ্রহ করে এবং বৈধতা যাচাই করে

পরিষেবা 3,4 - আরও মধ্যবর্তী পরিষেবা কল

পরিষেবা 5 - ব্যবহারকারীর ইন্টারফেস

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

এটি বেশ সাধারণ - তবে আমাদের নিখুঁত মানসিকতার সাথে আমরা প্রতিটি পরিষেবায় পিইটি অবজেক্টটি নকল করেছি। DRY (নিজেকে পুনরাবৃত্তি করবেন না) নীতিটি কেবলমাত্র একটি পরিষেবা অন্তর্ভুক্ত কোডের ক্ষেত্রে প্রযোজ্য এবং পরিষেবাগুলিতে প্রয়োগ হয় না তবে পয়েন্টটি এখনও আছে। আমরা যদি কোনও ক্ষেত্র যোগ করি তবে কী হবে ... আমাদের অবশ্যই প্রতিটিতে POJO এর 5 টি পরিষেবা পরিবর্তন করতে হবে।

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

প্রো এর / কন এর কি - সেরা নকশা কি? একইভাবে পোজো ক্লাস পুনরাবৃত্তি করতে গিয়ে ডি-কাপল থাকা অবস্থায় পরিষেবাগুলির মধ্যে ডেটা পাস করার জন্য আপনি কী করেছেন?


আল্লাহর বস্তু? en.wikipedia.org/wiki/God_object

@ ডাইকাইসিয়ান: নিশ্চয়ই আপনি পরামর্শ দিচ্ছেন না যে ওপি কোনও God শ্বরের অবজেক্ট নিয়ে যান, আপনি কি? এটিকে নিয়মিতভাবে একটি অ্যান্টি-প্যাটার্ন হিসাবে বিবেচনা করা হয়।
মাকোটো

আমি @ জাভাগুয়ের উত্তরের সাথে একমত

এবং আমি এটিও বলতে চাই, আপনি ভিজিটর-প্যাটার্নটি বিবেচনা করতে পারেন। en.wikedia.org/wiki/Visitor_ Pattern । কোনও পজোতে সমস্ত ক্ষেত্র এবং সেটার / গেটর তৈরি করুন এবং এটি মাইক্রোসার্ভেসিসের মধ্যে ভাগ করুন you আপনি যদি বিভিন্ন মাইক্রোসার্চিতে পোজোর উপর কিছু অপারেশন করতে চান তবে কিছু ভিজিটারক্লাস লিখুন।

ধন্যবাদ। এই 'সাধারণ লাইব্রেরি' থাকার সাথে আমার দ্বিধা হ'ল এটি বাড়বে। এবং সেখানে এমন বস্তু থাকবে যা কেবল 1 এবং 3 পরিষেবাগুলিতে বা 2 এবং 4, বা সমস্ত, বা কোনও সংমিশ্রণের যত্ন করে। এক ধরণের সাধারণ ডিটিও লাইব্রেরি প্যাকেজে যা সমস্ত ডিটিওর রয়েছে তা আমি ভাইস্টার প্যাটার্ন ব্যবহার করি বা সাধারণ ডিটিও পিওজিও না কি-না। এই সমস্ত অবজেক্টকে অন্তর্ভুক্ত করা কি তবে এটি যথাসম্ভব সেরা বজায় রাখার চেষ্টা করা কি গ্রহণযোগ্য? তাদের যদি প্রয়োজন হয় তাদের জন্য কমপক্ষে অবজেক্টগুলি সরবরাহ করা হয় যদি তারা সেগুলি ব্যবহার করতে চান ...

উত্তর:


5

সেরা নকশা কি?

আপনি ব্যাকএন্ড পরিষেবাগুলির মধ্যে একই Pet ডিটিও অবজেক্টটিকে পুনরায় ব্যবহার করতে পারেন (যা সাধারণত ব্যবসায়িক যুক্তি প্রক্রিয়াকরণ করে) তবে এটি যখন উপস্থাপনা স্তরের (ব্যবহারকারী ইন্টারফেস) আসে তখন সাধারণত ফর্মবিন ব্যবহার করা ভাল (যুক্ত ক্ষেত্রগুলির সাথে একটি আলাদা বিন) added উপস্থাপনা যুক্তির জন্য) যাতে উপস্থাপনা যুক্তি এবং ব্যবসায়িক যুক্তির মধ্যে একটি স্পষ্ট বিভাজন থাকবে

এটি প্রয়োজনীয় কারণ পরিষেবাগুলি পুনঃব্যবহারযোগ্য হওয়া উচিত এবং একক পরিষেবা একাধিক / বিভিন্ন শেষ পয়েন্টগুলি দ্বারা প্রকাশ করা / পুনঃব্যবহার করা যেতে পারে (যেমন ফ্রন্টএন্ড বা একটি ভিন্ন ওয়েবসার্ভিস ইত্যাদি হতে পারে)) এবং এই শেষের পয়েন্টগুলির প্রত্যেকটির জন্য অতিরিক্ত ক্ষেত্রের প্রয়োজন হতে পারে যা দ্বারা তৈরি করা হবে পরিষেবাগুলির উপরে সম্পর্কিত কন্ট্রোলার বা স্তর (অ্যাডাপ্টারের মতো)।

ডি-কাপল থাকাকালীন একই POJO ক্লাস পুনরাবৃত্তি কমাতে পরিষেবাগুলির মধ্যে ডেটা পাস করার জন্য আপনি কী করেছেন?

আপনি যদি ব্যবসায় এবং ওয়েব স্তরের মধ্যে একক শিম ব্যবহার করেন তবে আপনি প্রেজেন্টেশন লজিককে ব্যবসার যুক্তি দিয়ে শক্তভাবে সংযুক্ত করছেন যা ভাল অনুশীলন নয় এবং আপনি ফ্রন্ট্যান্ডে প্রয়োজনীয়তার জন্য পরিষেবাগুলি পরিবর্তন করবেন (উদাহরণস্বরূপ, একটি ভিন্ন তারিখের ফর্ম্যাট) ব্যবহারকারী ইন্টারফেসে প্রদর্শিত হবে)। এছাড়াও, পূর্ণ / মটরশুটি জুড়ে ডেটা কপি (FormBean বা Viceversa করার DTO মত) তোমার মতোই লাইব্রেরি ব্যবহার করতে পারেন এই প্রক্রিয়া করতে এ্যাপাচি BeanUtils.copyProperties() বা Dozer boilerplate কোড এড়াতে


আমি সম্মত হই যে উপস্থাপনা স্তরটি সম্ভবত প্রয়োজন অনুসারে বিভিন্ন বৈশিষ্ট্য সহ একটি উপস্থাপনা শিম হিসাবে আগত পেডলোডকে deserialize করা উচিত। তবে সাধারণভাবে সমস্ত ব্যাকএন্ড পরিষেবাদিতে একই ডিটিও অবজেক্ট (গুলি) পুনরায় ব্যবহার করা ঠিক হবে কি? আমরা প্রয়োজন কেবলমাত্র কয়েকটি পরিষেবার জন্য এই ডিটিও প্যাকেজগুলি ছোট প্যাকেজগুলিতে আলাদা করার চেষ্টা করব। আমি কোনও ডিটিও লাইব্রেরি প্যাকেজের কিছু আবর্জনা-ড্রয়ার পেয়ে ক্লান্ত হয়ে পড়েছি যাতে সমস্ত পরিষেবা নির্ভর করে এমন 75++ মাইক্রোসার্ভেসিসের জন্য ডিটিও থাকে। যদি না এটি ঠিক থাকে তবে এটি কেবল ডিটিও অবজেক্ট যা প্রথম স্থানে alচ্ছিক?

হ্যাঁ, সদৃশতা PetServicesএড়াতে আপনি একই ধরণের ব্যাকএন্ড পরিষেবাগুলিতে একই ডিটিও অবজেক্টটি পুনরায় ব্যবহার করতে পারেন । তবে আমার বক্তব্যটি দৃ couple়ভাবে দু'দিকের ব্যাকএন্ড এবং সম্মুখভাগ নয়, এটি that's
বিকাশকারী

4

ডিটিও যদি সমস্ত মাইক্রোসার্ভেসেসগুলিতে একই ব্যবসায়িক সত্তাকে প্রতিনিধিত্ব করে তবে সেবার মধ্যে ভাগ করা কেবলমাত্র একটি শ্রেণি থাকা উচিত। একই বস্তুর জন্য সদৃশ কোড থাকা কখনই (প্রায়) সঠিক নয়।


3
মাইক্রোসার্ফেসিসে ডিটিও ভাগ করে নেওয়া দুঃস্বপ্ন। "এই সংস্করণটির কি এই ক্ষেত্রটি ইতিমধ্যে রয়েছে? এইচএম হতে পারে?" আপনি কিছুক্ষণ পরে একটি বাস্তব জগাখিচুড়ি শেষ হবে। এই ক্ষেত্রে সদৃশ কোডটি ভাল।
মেজমো

1

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

এখন ব্যাকএন্ড-টু-ফ্রন্টএন্ড দেখুন এবং বিপরীতে আমি পূর্ববর্তী মন্তব্যের সাথে একমত নই যে উপস্থাপনা স্তরটি ইউআই হিসাবে আলাদা। এইটা না!!! ইউআই হ'ল আমার কাছে আর একটি মাইক্রোসার্ভিস যা ইভেন্টগুলি গ্রাস করে এবং উত্পাদন করে।

ব্যাকেন্ড-টু- ফ্রন্ট্যান্ডের দিকনির্দেশ আমি যা করি তা হ'ল POJO (dtos) কে টাইপস্ক্রিপ্ট ইন্টারফেস এবং প্যাকেজটিকে এনপিএম - তে রূপান্তর করা এবং সেগুলি নেক্সাসেও লোড করা। ইউআই নোডেজ ভিত্তিক প্রকল্পটি সেগুলি গ্রাস করে এবং ব্যবহার করে। এটি ইউআই-তে যাওয়ার পরিষেবা।

সামনের-থেকে-ব্যাকএন্ডের দিকের দিকের দিকনির্দেশে UI পরিষেবা স্তর ইভেন্টগুলিতে রূপান্তরিত করে আমি টাইপস্ক্রিপ্ট ইন্টারফেসগুলিকে রূপান্তর করি এবং সেগুলিকে POJOs (dtos) এ রূপান্তর করি এবং প্যাক প্যাকেজটিকে জেক আকারে নেক্সাসে (বা কিছু রেপো) আপলোড করি ব্যাকএন্ড পরিষেবাগুলি গ্রাস করার জন্য।

এই প্রক্রিয়াগুলি সহজেই সিআই প্রক্রিয়াগুলি দ্বারা পরিচালিত হয় (ট্র্যাভিস, গিটল্যাব সিআই, ইত্যাদি)

এই পদ্ধতির কোনও মন্তব্য স্বাগত জানাই।

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