এপিআই এবং অ্যাপ্লিকেশন মধ্যে অবজেক্ট ভাগ করার প্যাটার্ন


9

আমার ওয়েব অ্যাপ্লিকেশনটির নকশা সম্পর্কে আমার গুরুতর সন্দেহ হচ্ছে।

আমি ইন্টারফেস থেকে ব্যবসায়ের যুক্তি আলাদা করতে চেয়েছিলাম তাই আমি একটি ওয়েব এপিআই তৈরি করেছিলাম যা ডেটাবেজে সমস্ত অনুরোধগুলি পরিচালনা করে।

এটি সত্তা কাঠামো এবং কাজের এবং জেনেরিক রিপোজিটরি প্যাটার্নের একক সহ একটি এএসপি.নেট ওয়েব এপিআই। এখন পর্যন্ত, সবকিছু ভাল।

সমস্যা

যেখানে আমার সহায়তা দরকার তা হ'ল আমি এপিআই এবং অ্যাপ্লিকেশনটির মধ্যে অবজেক্টগুলি ভাগ করে নেওয়ার কার্যকর উপায়টি বের করতে পারি না।

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

এটি এখন কীভাবে বাস্তবায়ন হচ্ছে

আমার ইন্টারফেসটি সি # তে এএসপি.নেট ওয়েব অ্যাপ্লিকেশন এবং আমার এপিআই সি # তে রয়েছে, তাই আমি তাদের মধ্যে ভাগ করতে চাই আমার সমস্ত শ্রেণীর সংজ্ঞা দিয়ে একটি সাধারণ পাঠাগার তৈরি করেছি।

আমি জানি যে আমি যখন অ্যান্ড্রয়েড অ্যাপ বিকাশ করব তখন সমাধান কাজ করবে না, জাভাতে আবার আমার ক্লাস তৈরি করতে হবে তবে এটি আমার সবচেয়ে বড় সমস্যা নয়।

সমস্যাটি হ'ল আমার মনে হয় আমি সবসময় আমার জিনিসগুলিকে রূপান্তর করি।

EXAMPLE টি

আমার কাজের প্রবাহের উদাহরণ এখানে:

আমি আমার ফর্মটির জন্য সমস্ত অবজেক্ট এবং ডেটা টীকা সহ একটি মডেল দিয়ে শুরু করি তবে ব্যবহারকারী সেই মডেলটিকে একটি নিয়ামককে পোস্ট করবে।

কন্ট্রোলারে আমাকে এই মডেলটি আমার সাধারণ লাইব্রেরির একটি শ্রেণিতে রূপান্তর করতে হবে তারপরে সেই বিষয়টি আমার API এ প্রেরণ করতে হবে।

তারপরে আমার এপিআই-এর একটি নিয়ামক কলটি ধরেন এবং সেই অধ্যায়টিকে ডাটাবেস আপডেট করতে কোনও সত্তা অবজেক্টে রূপান্তরিত করুন।

সুতরাং আমি 3 ক্লাস আছে

  1. যাচাইকরণের জন্য সমস্ত ডেটা টীকা সহ দর্শনটির মডেল (ক্লায়েন্ট)
  2. অবজেক্টগুলি ভাগ করার জন্য সাধারণ পাঠাগার ক্লাস (ডিএলএল)
  3. সত্তা ক্লাস (এপিআই)

আমার অনুভূতি আছে যে আমি সত্যিই কিছু ভুল করছি। আরও কি মার্জিত কিছু আছে? প্রকল্পটি আরও বড় হওয়ার আগে আমি এই সমস্যার জন্য আমার একটি ভাল সমাধান পেয়েছি তা নিশ্চিত করতে চাই।


আমার প্রশ্নটি পরিষ্কার না হলে প্রশ্ন জিজ্ঞাসা করতে দ্বিধা করবেন না।
মার্ক

আমার কাছে এটি পরিষ্কার নয় যে আপনি কোন আর্কিটেকচারটি প্রয়োগ করেছেন (সম্ভবত এটি আমার কাছে ধাঁধা ধাঁধা)।
অ্যান্ডি

হ্যাঁ আমার কাছে একটি ওয়েব অ্যাপ্লিকেশন রয়েছে যা একটি ওয়েব এপিআই ব্যবহার করে। এপিআই হ'ল ডেটাবেস সহ ব্যবসায় যুক্তিযুক্ত।
মার্ক

উত্তর:


12

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

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

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

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

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

আমি এই জাতীয় বিভিন্ন বস্তুর মধ্যে রূপান্তর কোড লেখাকে ঘৃণা করি তবে আমার সমাধান সাধারণত নিম্নলিখিতগুলির মধ্যে একটি হয়:

  • আপনার জন্য বেশিরভাগ অবজেক্ট রূপান্তর ভারী উত্তোলন করে এমন একটি লাইব্রেরি ব্যবহার করুন - উদাহরণস্বরূপ, আপনি যদি সি # ব্যবহার করেন আপনি দুর্দান্ত অটোম্যাপার লাইব্রেরি ( http://automapper.org/ ) ব্যবহার করতে পারেন । আমি বিশ্বাস করি যে এর মতো আরও কয়েকটি লাইব্রেরি রয়েছে, তবে আমি এখনও অবধি দেখা সবচেয়ে শক্তিশালী অটোম্যাপার।
  • আপনি যদি কোনও লাইব্রেরি খুঁজে না পেয়ে আপনাকে আপনার অবজেক্ট রূপান্তর করতে সহায়তা করেন তবে তাদের মধ্যে রূপান্তর করার জন্য ইউটিলিটি পদ্ধতির একটি সেট লিখুন। এটি স্তন্যপান করতে পারে, তবে এটি দীর্ঘমেয়াদে মূল্যবান, রূপান্তর পদ্ধতিটি প্রথমবার যখন আপনাকে কোনও রূপান্তর করতে হবে তখন লিখুন - অপেক্ষা করবেন না।

আপনার ব্যাখ্যার জন্য আপনাকে ধন্যবাদ তবে আমি এখনও কিছু বুঝতে অসুবিধা বোধ করি। আমি বুঝতে পারছি না কেন ডেটা ট্রান্সফারের স্তরের কোনও বৈধতা নেই? আমি যদি আমার পরবর্তী মোবাইল অ্যাপের জন্য কিছু বৈধতা ভুলে যাই তবে কী হবে? আমার ডাটাবেস মডেলটিতে ব্যতিক্রম না করার পরিবর্তে আমি যখন এপিআই কল করি তখন কমপক্ষে এটি বৈধ হবে না। আমি নিশ্চিত যে আমি বুঝতে পারি না।
মার্ক

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

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

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

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