ডিটিওগুলির জন্য রচনা এবং উত্তরাধিকার ব্যবহার করুন


13

আমাদের একটি এএসপি.নেট ওয়েব এপিআই রয়েছে যা আমাদের একক পৃষ্ঠা অ্যাপ্লিকেশনটির জন্য একটি REST এপিআই সরবরাহ করে। আমরা এই API এর মাধ্যমে ডেটা পাস করার জন্য ডিটিও / পিওসিও ব্যবহার করি।

সমস্যাটি এখন, এই ডিটিওগুলি সময়ের সাথে সাথে বড় হচ্ছে, তাই এখন আমরা ডিটিওগুলিকে রিফেক্টর করতে চাই।

আমি কীভাবে একটি ডিটিও ডিজাইন করবেন "সেরা অনুশীলনগুলি" সন্ধান করছি: বর্তমানে আমাদের কাছে ছোট ডিটিও রয়েছে যা কেবলমাত্র মান-ধরণের ক্ষেত্রগুলি নিয়ে গঠিত, যেমন:

public class UserDto
{
    public int Id { get; set; }

    public string Name { get; set; }
}

অন্যান্য ডিটিওরা এই ইউজারডটো রচনা দ্বারা ব্যবহার করেন, যেমন:

public class TaskDto
{
    public int Id { get; set; }

    public UserDto AssignedTo { get; set; }
}

এছাড়াও, কিছু বর্ধিত ডিটিও রয়েছে যা অন্যের কাছ থেকে উত্তরাধিকার সূত্রে সংজ্ঞায়িত করা হয়, যেমন:

public class TaskDetailDto : TaskDto
{
    // some more fields
}

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

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


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

@ লাইভ এটি প্রশ্নের সঠিক উত্তর, ঠিক নেই। আপনি কেন এটিকে মন্তব্য হিসাবে রেখেছেন তা নিশ্চিত নন
থেটিক্সহিস্পেরার

2
@ লাইভ: এর পরিবর্তে আপনি কী ব্যবহার করবেন? আমার অভিজ্ঞতায়, এই লোকেরা যাঁরা এর সাথে লড়াই করছেন তারা কেবল এটিকে ওভারথাইচিং করছেন। একটি ডিটিও হ'ল ডেটার জন্য কেবল একটি ধারক এবং এটিই কেবল।
রবার্ট হার্ভে

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

: একটি ভাল আলোচনা আপনি সাহায্য করতে পারে এই চেষ্টা stackoverflow.com/questions/6297322/...
জনি

উত্তর:


10

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

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

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

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


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

1
@ সরকারী - সাধারণভাবে, হ্যাঁ
জন রায়নর 14

2

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

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


রবার্ট, আপনি কি এখানে একটি সমষ্টিগত রুট বলতে চাচ্ছেন?
জননি

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

সমস্ত ডেটা প্রয়োজনীয়?
রবার্ট হার্ভে

1

"নমনীয়" বা ডিটিও হিসাবে অ্যাবস্ট্রাক্ট কোনও কিছুর জন্য সর্বোত্তম অনুশীলন স্থাপন করা শক্ত। মূলত, ডিটিওগুলি কেবল ডেটা স্থানান্তরের জন্য অবজেক্ট তবে গন্তব্য বা স্থানান্তরের কারণের উপর নির্ভর করে আপনি বিভিন্ন "সেরা অভ্যাস" প্রয়োগ করতে চাইতে পারেন।

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

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

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

এখন, উত্তরাধিকার সহ, কোডের পুনরায় ব্যবহারটি মূল উদ্দেশ্যগুলির চেয়ে উত্তরাধিকারের পার্শ্ব-প্রতিক্রিয়াটির মতো; অন্যদিকে রচনাটি মূল উদ্দেশ্য হিসাবে কোড পুনরায় ব্যবহারের মাধ্যমে প্রয়োগ করা হয়।

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

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

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

public void DoSomething(BaseDTO base) {
    //Some code 
}

যদি কোনও পদ্ধতির কোনও নিজস্ব ডিটিওর প্রয়োজন হয় তবে আমি উত্তরাধিকার করি এবং সাধারণত আমার কেবলমাত্র পরিবর্তনটি করা দরকার তা হ'ল প্যারামিটার, যদিও কখনও কখনও নির্দিষ্ট মামলার জন্য আরও গভীর খনন করতে হয়।

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

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


আমি আমার উত্তরে 2 টির বেশি লিঙ্ক যুক্ত করতে পারি নি, স্থানীয় ডিটিও সম্পর্কে আরও কিছু তথ্য এখানে । আমি সচেতন যে এটি খুব পুরানো তথ্য তবে আমি মনে করি এটির কিছু এখনও প্রাসঙ্গিক।
ইভানগ্রস

1

ডিটিওতে রচনা ব্যবহার করা একদম সূক্ষ্ম অনুশীলন।

কংক্রিট ধরণের ডিটিও-র মধ্যে উত্তরাধিকার হ'ল একটি খারাপ অভ্যাস।

একটি জিনিসের জন্য, সি # এর মতো একটি ভাষায়, একটি স্বয়ংক্রিয়-প্রয়োগকৃত সম্পত্তির খুব সামান্য রক্ষণাবেক্ষণের ওভারহেড থাকে তাই সেগুলি অনুলিপি করা (আমি সত্যই নকলটিকে ঘৃণা করি) এটি প্রায়শই হিসাবে ক্ষতিকারক নয়।

ডিটিওগুলির মধ্যে কংক্রিটের উত্তরাধিকার ব্যবহার না করার একটি কারণ হ'ল নির্দিষ্ট সরঞ্জামগুলি আনন্দের সাথে এগুলি ভুল প্রকারে ম্যাপ করে।

উদাহরণস্বরূপ, আপনি যদি ডিপারের মতো একটি ডেটাবেস ইউটিলিটি ব্যবহার করেন (আমি এটির প্রস্তাব দিই না তবে এটি জনপ্রিয়) যা class name -> table nameঅনুমান সম্পাদন করে তবে আপনি সহজেই ডাইরেক্টেড টাইপটি হায়ারার্কির কোথাও একটি কংক্রিট বেস টাইপ হিসাবে সংরক্ষণ করতে পারেন এবং এর ফলে ডেটা হারাতে পারেন বা আরও খারাপ ।

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

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

যদিও কংক্রিটের ধরণের উত্তরাধিকার ফলস্বরূপ, এই জাতীয় ধারাবাহিকতা নিশ্চিত করতে সহায়তা করে, সেই ধরণের ধারাবাহিকতা বজায় রাখতে ইন্টারফেসগুলি (বা সি ++ এর বিশুদ্ধ ভার্চুয়াল বেস শ্রেণি) ব্যবহার করা আরও ভাল।

নিম্নলিখিত ডিটিও বিবেচনা করুন

interface IIdentity
{
    int Id { get; set; }
}

interface INamed
{
    string Name { get; set; }
}

public class UserDto: IIdentity, INamed
{
    public int Id { get; set; }

    public string Name { get; set; }

    // User specific properties
}

public class TaskDto: IIdentity
{
    public int Id { get; set; }

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