ডেটা ট্রান্সফার অবজেক্ট কী?

218

এমভিসিতে মডেল ক্লাসগুলি ডিটিও হয় এবং যদি না হয় তবে কী পার্থক্য রয়েছে এবং আমাদের উভয়ের কী দরকার?

@ ইয়েগোর 256 এবং সত্য, এই নিবন্ধের সেই বইটি কীভাবে এপিআই থেকে ডেটা পুনরুদ্ধার করতে পারে এবং কীভাবে ডেবিতে ডেটা সংরক্ষণ করতে পারে, এবং এসআরপি লঙ্ঘন করা ঠিক আছে?

— বেতলিস্টা

222

ডেটা ট্রান্সফার অবজেক্ট হ'ল একটি অবজেক্ট যা ডেটা এনপ্যাপুলেট করতে ব্যবহৃত হয় এবং এটি কোনও অ্যাপ্লিকেশনটির একটি সাবসিস্টেম থেকে অন্যটিতে প্রেরণ করে।

ডিটিওগুলি নিজের এবং ইউআই স্তরের মধ্যে ডেটা স্থানান্তর করতে N-Tier অ্যাপ্লিকেশনটিতে পরিষেবা স্তর দ্বারা সর্বাধিক ব্যবহৃত হয়। এখানে মূল সুবিধাটি হ'ল এটি বিতরণের অ্যাপ্লিকেশনগুলিতে তারের জুড়ে প্রেরণ করা দরকার এমন ডেটার পরিমাণ হ্রাস করে। তারা এমভিসি প্যাটার্নে দুর্দান্ত মডেলও তৈরি করে।

ডিটিওগুলির জন্য অন্য ব্যবহারটি পদ্ধতি কলগুলির জন্য প্যারামিটারগুলি সজ্জিত করতে পারে। যদি কোনও পদ্ধতি 4 বা 5 টির বেশি পরামিতি নেয় তবে এটি কার্যকর হতে পারে।

ডিটিও প্যাটার্নটি ব্যবহার করার সময়, আপনি ডিটিও এসেম্বলারেরও ব্যবহার করতে পারেন। সমাবেশকারীরা ডোমেন অবজেক্টগুলি থেকে ডিটিও তৈরি করতে এবং তার বিপরীতে ব্যবহৃত হয়।

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

— বেনি হ্যালেট
সূত্র

7

"ডিটিও এমভিসি প্যাটার্নে দুর্দান্ত মডেল তৈরি করে" - তবে কোনও মডেলটিতে অবজেক্টের সমস্ত ডেটা এবং ডিটিওর ডেটার অংশ দিয়ে অনুকূলিত হওয়া উচিত নয়? আমার কাছে যদি মডেল এ এবং আমার দুটি সাবসিস্টিমে এটি পাস করার দরকার হয় তবে কি প্রতিটিটির প্রাসঙ্গিক ক্ষেত্রের সাথে A_DTO_1 এবং A_DTO_2 থাকবে? "ডিটিওগুলি পদ্ধতি কলগুলির জন্য প্যারামিটারগুলি encapsulate করা যেতে পারে" -> সুতরাং প্যারামিটারগুলি মোড়ানো প্রতিটি শ্রেণি কি এই বিতরণকারী সিস্টেমটি না হলেও ডিটিও হয়? এমভিসি-র মডেলগুলি কি ডোমেন অবজেক্ট নয়?

— ইয়ারন নাভেহ

2

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

— বেনি হাললেট

12

"ডিটিও-র অন্য ব্যবহারের জন্য পদ্ধতি কলগুলির জন্য প্যারামিটারগুলি আবশ্যক to এটি কোনও ক্ষেত্রে যদি 4 বা 5 টি পরামিতির বেশি লাগে তবে এটি কার্যকর হতে পারে।" এটি আসলে একটি পাল্টেজিস্ট বা জিপসি ওয়াগন শ্রেণি নামে একটি বিরোধী-নিদর্শন। আপনার পদ্ধতির যদি 4 টি আর্গুমেন্টের প্রয়োজন হয় তবে এটি 4 দিন, কেবল কোনও বস্তুকে পদ্ধতি বা শ্রেণিতে স্থানান্তর করতে কোনও শ্রেণি তৈরি করবেন না।

— উইক্স

2

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

— আরাম কোচার্যান

3

ডিটিওগুলি পদ্ধতি কলগুলির জন্য প্যারামিটারগুলি encapsulate করতে ব্যবহার করা উচিত নয় (যা তাদের লোকালডিটিও করে তুলবে), তারা দূরবর্তী ইন্টারফেসের প্রসঙ্গে পরিচয় করিয়ে দেওয়া হয়েছিল: martinfowler.com/bliki/LocalDTO.html

— রুই

28

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

— ব্লু
সূত্র

22

একটি ডিটিও একটি বোবা বস্তু - এটি কেবল বৈশিষ্ট্য রাখে এবং সেটার এবং সেটটার রয়েছে তবে কোনও তাত্পর্য ছাড়া অন্য কোনও যুক্তি (সম্ভবত তুলনা () বা সমান () বাস্তবায়ন) ব্যতীত অন্য কোনও যুক্তি নেই।

সাধারণত এমভিসিতে মডেল ক্লাস (এখানে নেট নেট এমভিসি ধরে নেওয়া) ডিটিও, বা ডিটিওগুলির সংগ্রহ / সংগ্রহ

— এরিক পেট্রোলেজে
সূত্র

3

আপনি যা বর্ণনা করছেন তা একটি লোকালডিটিও: মার্টিনফাউলার

— রুই

3

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

— অমিতাভা

14

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

|-----------|                                                   |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------|                                                   |--------------|

উত্তরাধিকারে জাভা এন্টারপ্রাইজ সিস্টেম ডিটিওগুলিতে এতে বিভিন্ন ইজেবি স্টাফ থাকতে পারে।

আমি জানি না এটি একটি সেরা অনুশীলন বা না তবে আমি ব্যক্তিগতভাবে আমার স্প্রিং এমভিসি / বুট প্রকল্পগুলিতে মান অবজেক্টগুলি ব্যবহার করি :

        |------------|         |------------------|                             |------------|
-> Form |            | -> Form |                  | -> Entity                   |            |
        | Controller |         | Service / Facade |                             | Repository |
<- View |            | <- View |                  | <- Entity / Projection View |            |
        |------------|         |------------------|                             |------------|

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

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

User Service ----> XX CANNOT CALL XX ----> Order Service

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

উদাহরণস্বরূপ এটি আমাদের ব্যবহারকারী সত্তা:

@Entity
public final class User {
    private String id;
    private String firstname;
    private String lastname;
    private String phone;
    private String fax;
    private String address;
    // Accessors ...
}

তবে আপনার ব্যবহারকারীর একটি পৃষ্ঠাযুক্ত তালিকাটি ফিরিয়ে আনতে হবে যাতে কেবল আইডি, প্রথম নাম, পদবি অন্তর্ভুক্ত থাকে। তারপরে আপনি ওআরএম অভিক্ষেপের জন্য একটি ভিউ মান অবজেক্ট তৈরি করতে পারেন।

public final class UserListItemView {
    private String id;
    private String firstname;
    private String lastname;
    // Accessors ...
}

আপনি সহজেই সংগ্রহস্থল স্তর থেকে পৃষ্ঠাযুক্ত ফলাফল পেতে পারেন। বসন্তকে ধন্যবাদ আপনি অনুমানের জন্য কেবল ইন্টারফেসও ব্যবহার করতে পারেন।

List<UserListItemView> find(Pageable pageable);

অন্যান্য রূপান্তর ক্রিয়াকলাপের BeanUtils.copyপদ্ধতিটি ঠিকঠাক কাজ করার জন্য চিন্তা করবেন না ।

— Fırat KÜÇÜK
সূত্র

11

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

— থিয়াগো বুর্গোস
সূত্র

ব্যবসায়ের যুক্তি নিয়ন্ত্রণকারীদের মধ্যে থাকা উচিত কেন?

— অ্যালেক্সিওয়ে

6

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

উইকিপিডিয়া থেকে :

ডেটা ট্রান্সফার অবজেক্ট (ডিটিও), যা পূর্বে মান বস্তু বা ভিও হিসাবে পরিচিত, এটি একটি নকশার প্যাটার্ন যা সফ্টওয়্যার অ্যাপ্লিকেশন সাবসিস্টেমগুলির মধ্যে ডেটা স্থানান্তর করতে ব্যবহৃত হয় to ডিটিওগুলি প্রায়শই ডেটাবেস থেকে ডেটা পুনরুদ্ধার করতে ডেটা অ্যাক্সেস অবজেক্টের সাথে একত্রে ব্যবহৃত হয়।

— দেনিযেল
সূত্র

3

একটি মান বস্তু একটি ডিটিও নয় ।

— কোডারপিসি

0

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

— মোস্তফা কাজেমী
সূত্র

0

DefN

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

বিপরীতে, গতিশীল মডেল বা "প্রপার্টি ব্যাগ" রানটাইমের সময় উত্পাদন প্রক্রিয়া তৈরি হওয়ার সময় ডেটা রেকর্ডকে মডেলিংয়ের সমস্যা সমাধান করে।

Cvar

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

    class Cvar { ... }

    class Cvar<T> : Cvar
    {
        public T Value { get; set; }
    }

    class MyDTO
    {
        public Cvar<int> X { get; set; }
        public Cvar<int> Y { get; set; }
        public Cvar<string> mutableString { get; set; } // >;)
    }

সূত্র: http://www.powersemantics.com/

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

    // a dynamic DTO
    class CvarRegistry : Dictionary<string, Cvar> { }

contentions

দ্রষ্টব্য: যেহেতু উইক্স প্যারামিটারগুলিকে "অ্যান্টি-প্যাটার্ন" হিসাবে সংগঠিত করার জন্য ডিটিও ব্যবহারের লেবেলযুক্ত, তাই আমি একটি অনুমোদিত মতামত দেব।

    return View(model);  // MVC disagrees

আমার সহযোগিতামূলক আর্কিটেকচার ডিজাইনের নিদর্শনগুলিকে প্রতিস্থাপন করে। আমার ওয়েব নিবন্ধ পড়ুন।

প্যারামিটারগুলি স্ট্যাক ফ্রেম মেশিনের তাত্ক্ষণিক নিয়ন্ত্রণ সরবরাহ করে। আপনি যদি অবিচ্ছিন্ন নিয়ন্ত্রণ ব্যবহার করেন এবং অতএব তাত্ক্ষণিক নিয়ন্ত্রণের প্রয়োজন না হয় তবে আপনার মডিউলগুলির পরামিতিগুলির প্রয়োজন নেই। আমার আর্কিটেকচারের কিছুই নেই। প্রক্রিয়াগুলি মেশিনগুলির (পদ্ধতিগুলি) কনফিগারেশন জটিলতা যুক্ত করে তবে মান (কর্মক্ষমতা) যুক্ত করে যখন পরামিতিগুলি মান ধরণের হয়। যাইহোক, রেফারেন্স ধরণের পরামিতিগুলি গ্রাহককে যে কোনও উপায়ে স্তূপ থেকে নামিয়ে ফেলতে সহায়তা করে - সুতরাং, কেবল গ্রাহককে রেফারেন্স বৈশিষ্ট্য সহ কনফিগার করুন। মেকানিকাল ইঞ্জিনিয়ারিংয়ের ঘটনা: প্যারামিটারগুলির উপর নির্ভরতা এক প্রিপটিমাইজেশন, কারণ প্রক্রিয়াজাতকরণ (উপাদান তৈরি করা) নিজেই অপচয় waste আরও তথ্যের জন্য আমার ডাব্লু নিবন্ধ পড়ুন। http://www.powersemantics.com/w.html ।

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

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

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

— RBJ
সূত্র