পরিষেবা স্তর তৈরি করা কতটা জরুরি?

Question

আমি 3 টি স্তরে (ডাল, বিএল, ইউআই) অ্যাপ্লিকেশন তৈরি করা শুরু করেছি [এটি মূলত সিআরএম, কিছু বিক্রয় প্রতিবেদন এবং জায়গুলি পরিচালনা করে]।

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

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

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

আমি এটিতে গুগল দেওয়ার চেষ্টা করেছি কিন্তু আমি এখনও বিভ্রান্ত হয়েছি এবং কী করব তা সিদ্ধান্ত নিতে পারছি না।

Answer 1

মার্টিন ফওলারের বই "প্যাটার্নস অফ এন্টারপ্রাইজ আর্কিটেকচার" তে বলা হয়েছে:

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

তবে আপনি যখন দ্বিতীয় ধরণের ক্লায়েন্ট, বা ব্যবহারের ক্ষেত্রে প্রতিক্রিয়াতে দ্বিতীয় লেনদেনের সংস্থান হিসাবে কল্পনা করবেন তখনই এটি শুরু থেকেই সার্ভিস লেয়ারে ডিজাইন করার জন্য অর্থ প্রদান করে।

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

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

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

সংক্ষেপে, একটি পরিষেবা স্তর ব্যবহার করা ভাল - আরও-তাই আমি মনে করি আপনার উদাহরণটি আপনি সরবরাহ করেছেন যেমন মনে হয় আপনার কাছে ব্যবসায়িক যুক্তির একাধিক ক্লায়েন্ট রয়েছে।

Comments

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

— PSr

আমি আপনার অনুচ্ছেদটি বেশ বুঝতে পারি নি With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations- যদি এটি সমস্ত একাধিক ইউআই সম্পর্কে হয় তবে সিআরইউডি এখানে কীভাবে প্রবেশ করবে? আর যদি সিআরইউডি পরিষেবাদিগুলির সাথে ভালভাবে চলে যায় তবে আমার একাধিক ইউআই প্রয়োজন না থাকলে আমি এখনও একটি পরিষেবা স্তর তৈরি করতে পারতাম না, যদি আমি সঠিকভাবে বুঝতে পারি এবং আমি সত্যই আশা করি যে আমি জিনিসগুলি সহজ রাখতে পছন্দ করি কারণ (সার্ভিস স্তরটি হ'ল একটি আমার অনভিজ্ঞ মতামত নিয়ে

— গণ্ডগোল করুন

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

— ফিল প্যাটারসন

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

— ডেকো

আপনি একটি পরিষেবা স্তর একটি উদাহরণ প্রদান করতে পারেন?

— user962206

Answer 2

একটি পরিষেবা স্তর যুক্ত করা হচ্ছে কারণ আপনি ধারণার মূল্যায়ন করেছেন এবং এটির সর্বোত্তম পদ্ধতির সমাপ্তি করেছেন: ভাল

একটি পরিষেবা স্তর যুক্ত করা কারণ এটি শীতল বাচ্চারা করছে: খারাপ

যদি আপনার অন্ত্রে বলে যে আপনার কোনও প্রয়োজন নেই, তবে একটি তৈরি করবেন না।

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

কোনও পরিষেবা স্তরের সাথে ভুল বা সঠিক কিছুই নেই - এটি একটি বিশেষ পদ্ধতির যার উপযুক্ততার হাত ধরে এই প্রকল্পের জন্য প্রযুক্তিগত যোগ্যতার ভিত্তিতে মূল্যায়ন করা উচিত। আপনার নিজের সিদ্ধান্তের জন্য অন্য ব্যক্তির মতামতগুলি প্রতিস্থাপন করতে বাধ্য হবেন না।

Comments

এটি বিষয়টিকে মোটেও সম্বোধন করে না, এটি কেবল উন্নয়নের চর্চা সম্পর্কে একটি কম্বল স্টেটমেন্ট / কৌতুক দেয় যা কয়েকটি শব্দের পরিবর্তে এই সাইটের কোনও প্রশ্ন সম্পর্কে প্রয়োগ করতে পারে। এই উত্তরটি পড়া থেকে, আমি এমনকি প্রতীত আপনাকে জানাতে চাই যে ঠিক কি একটি সেবা স্তর নই হয় ।

— অ্যারোনআউট

এটি অবশ্যই অন্যান্য প্রশ্নের ক্ষেত্রে প্রয়োগ করা যেতে পারে ... এটি কম সত্য করে তোলে না। তাঁর প্রকল্পে তাঁর কী প্রয়োজন তা জানানোর জন্য আপনার বা আমার কাছে প্রয়োজনীয় প্রসঙ্গের কাছাকাছি কোথাও নেই, সুতরাং তাকে হ্যাঁ তার এটি প্রয়োজন, বা না তিনি বলছেন, এটি কেবল একটি সমালোচনা এবং অব্যর্থহীন। ওপিকে এখানে যা প্রয়োজন তা সঠিক সিদ্ধান্তগুলি জানার জন্য সিদ্ধান্ত নিতে কিছুটা নৈতিক সমর্থন।

— গ্র্যান্ডমাস্টারবি

@ অ্যারোনট উত্তর সঠিকভাবে নির্বিশেষে, তিনি এখনও মূলত উত্তর দিচ্ছেন, "একটি পরিষেবা স্তর কতটা জরুরি?" তিনি দাবি করেন যে এটি একেবারে অপরিহার্য নয় এবং এটি সম্ভবত একটি অতিমাত্রায়। আপনি যদি উত্তরটির সাথে একমত না হন তবে দয়া করে ডাউনওয়েট করুন।

— maple_shaft

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

— maple_shaft

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

— গ্র্যান্ডমাস্টারবি

Answer 3

অনেকগুলি কারণ রয়েছে যা একটি পরিষেবা স্তর তৈরি করার সিদ্ধান্ত নেয়। নিম্নলিখিত কারণে আমি অতীতে পরিষেবা স্তর তৈরি করেছি created

1. একাধিক ক্লায়েন্ট দ্বারা পুনরায় ব্যবহার করা দরকার কোড।
2. তৃতীয় পক্ষের লাইব্রেরিগুলির জন্য আমাদের সীমিত লাইসেন্স রয়েছে।
3. তৃতীয় পক্ষগুলির জন্য আমাদের সিস্টেমে একটি ইন্টিগ্রেশন পয়েন্ট দরকার।
4. সদৃশ ব্যবসায়ের যুক্তিটিকে কেন্দ্রিককরণ।

কেস 1: আপনি বেস কার্যকারিতা তৈরি করছেন যা বিভিন্ন ক্লায়েন্টের একটি অগণিত দ্বারা ব্যবহার করা দরকার। বাক্সের ঠিক বাইরে আপনার সরবরাহিত কার্যকারিতাটি ট্যাপ করতে বিভিন্ন ক্লায়েন্টের জন্য পরিষেবা স্তরটি কার্যকারিতা তৈরি করে।

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

কেস 3: আপনি তৃতীয় পক্ষের সাথে যোগাযোগের জন্য কার্যকারিতা তৈরি করছেন। আপনার উদাহরণে আপনি বিক্রেতাদের আগত পণ্য শিপমেন্ট সম্পর্কে বার্তা দেওয়ার অনুমতি দেওয়ার জন্য একটি ইনভেন্টরি এন্ডপয়েন্ট স্থাপন করতে পারেন।

কেস ৪: আপনি আপনার কোড এন্টারপ্রাইজটি প্রশস্ত করে বিশ্লেষণ করেছেন এবং দেখতে পেয়েছেন যে পৃথক দলগুলি একই জিনিস তৈরি করেছে (কেবল কিছুটা ভিন্নভাবে প্রয়োগ করা হয়েছে)। একটি পরিষেবা স্তর দিয়ে আপনি সেরা পদ্ধতির বাছাই করতে পারেন এবং এখন আপনি সমস্ত টিমগুলিকে পরিষেবাতে কল করে এই প্রক্রিয়াটি একইভাবে প্রয়োগ করতে পারেন। যুক্তি যুক্তিযুক্ত করার আরেকটি সুবিধা হ'ল যখন বাগগুলি পাওয়া যায়। এখন আপনি একবারে স্থির স্থাপনা করতে পারবেন এবং সমস্ত ক্লায়েন্ট একই সাথে সুবিধা উপভোগ করতে পারবেন।

এই সমস্ত বলা একটি পরিষেবা স্তর সম্ভাব্য নেতিবাচক আছে।

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

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

Comments

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

— BornToCode

আপনাকে স্বাগতম! উভয় উত্তর থেকে দূরে সরে যাওয়ার মূল বিষয়টি হ'ল এটি (প্রধানত) একাধিক ক্লায়েন্ট থাকা উচিত যা একই জিনিসটি করা উচিত maintenance পরিষেবাটি ব্যবহার করে বেশি সংখ্যক ক্লায়েন্ট, আপনার জন্য রক্ষণাবেক্ষণের পরিমাণটি তত বেশি।

— ফিল প্যাটারসন

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

— gbjbaanb

Answer 4

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

সিকিউআরএস এই সমস্যাগুলি সমাধান করে এবং আপনাকে সেগুলির মধ্যে একটি পদ্ধতিগত পরিষেবা স্তর তৈরি করতে বাধা দেয়।

Comments

কার স্ট্যান্ডার্ড দ্বারা ভাল নির্মিত? অবশ্যই ওও মান দ্বারা একটি পরিষেবা স্তর ইন্টারফেস একটি জগাখিচির সম্পূর্ণ ট্রেনের ধ্বংস of কার্যকরী বা পদ্ধতিগত দৃষ্টিকোণ থেকে তারপর এটি একটি সুন্দর স্তরযুক্ত নকশা পদ্ধতির উত্সাহ দেয়। আমি মনে করি পরিষেবা স্তরগুলির সাথে লোকদের সবচেয়ে বড় হ্যাং আপ হ'ল তারা স্টেটলেস লেনদেন ভিত্তিক অ্যাপ্লিকেশনকে উত্সাহ দেয় এবং খাঁটি অবজেক্ট ওরিয়েন্টেড পদ্ধতির নিরুৎসাহিত করে। আমি যুক্তির উভয় পক্ষই বুঝতে পারি।

— maple_shaft

Answer 5

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

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

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

পিএস যদি আপনি জাভাতে কাজ করছেন তবে জোশুয়া ব্লচের কার্যকর জাভা বইয়ে তাঁর দুর্দান্ত ইন্টারফেসের পরামর্শ রয়েছে।

Comments

জীবাণুমুক্ত তত্ত্বগুলি ছাড়াই দুর্দান্ত উত্তর।

— ড্যানিলো

Answer 6

আমি আপনার সাথে একমত. আপনি যদি একক UI ব্যবহার করেন তবে আর একটি স্তর অন্তর্ভুক্ত করার দরকার নেই।

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

আরেকটি শেনেরিও হ'ল আপনার অ্যাপ্লিকেশনটিতে একাধিক ইউআই ব্যবহার করা, এই ক্ষেত্রে ইউআই হ্যান্ডল করার জন্য একটি পরিষেবা স্তর থাকা ভাল।

স্ট্যাক ওভারফ্লো: পরিষেবা স্তর প্যাটার্ন নিয়ে আলোচনা

Comments

সুতরাং আপনি কি পরামর্শ দেন যে প্রতিটি জটিল অ্যাপ্লিকেশনটিতে তার একটি পরিষেবা স্তর ব্যবহার করা উচিত এবং কেবল ডাল, বিএল, ইউআই স্তরগুলির জন্য নিষ্পত্তি করা উচিত নয়?

— BornToCode

একাধিক UI এর ক্ষেত্রে আমাদের অবশ্যই একটি পরিষেবা স্তর অন্তর্ভুক্ত করতে হবে। আপনার ক্ষেত্রে আমি মনে করি না যে একটি নতুন স্তর প্রস্তুত করার প্রয়োজন আছে। এটি কেবলমাত্র প্রয়োগের জটিলতা বাড়ায়।

— সতীশ পান্ডে

Answer 7

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