ব্যবসায়িক বিষয় - ধারক বা কার্যকরী?

Question

এটি এমন একটি প্রশ্ন যা আমি এসও-তে ফিরে কিছুক্ষণ জিজ্ঞাসা করেছি, তবে এটি এখানে আরও ভাল আলোচনা হতে পারে ...

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

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

যুক্তির এক লাইন বলছে যে বস্তুটিকে কার্যকারিতা (একক দায়িত্বের মূল) থেকে আলাদা করুন এবং কার্যকারিতাটি একটি ব্যবসায়িক লজিক স্তর বা অবজেক্টে রাখুন।

অন্য যুক্তির পংক্তিটি বলছে, না, আমার যদি গ্রাহক অবজেক্ট থাকে তবে আমি কেবল গ্রাহককে সেভ করতে চাই এবং সেভ করে তা করা হবে। আমি যদি অবজেক্টটি গ্রাস করছি তবে গ্রাহককে বাঁচাতে কেন অন্য ক্লাস সম্পর্কে জানতে হবে?

আমাদের শেষ দুটি প্রকল্পের বস্তুগুলি কার্যকারিতা থেকে পৃথক করা হয়েছিল, তবে নতুন প্রকল্পটি নিয়ে আবার বিতর্ক উত্থাপিত হয়েছে।

কোনটি আরও বোধ করে এবং কেন ??

Comments

আপনি কি আমাদের আপনার প্রকল্প সম্পর্কে আরও বলতে পারেন? আপনার প্রকল্পের প্রকৃতি নির্ধারণ করবে কোন সমাধানটি আরও ভাল।

Answer 1

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

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

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

public static CustomerDTO GetDTO(Customer c) { /* ... */ }

public static Customer GetCustomer(CustomerDTO cdto) { /* ... */ }

সুতরাং, সংক্ষেপে, এটি ডোমেনে লজিক্যাল অপারেশনের সাথে একমত যে কোনও ডোমেন অবজেক্টে ক্রিয়াকলাপ তৈরি করে নিখুঁত করে তোলে।

বিষয়টি নিয়ে বেশ কয়েকটি ভাল আলোচনার জন্য গুগল 'দৃistence়তা উপেক্ষা' এর জন্য ( এই এসও প্রশ্ন , এবং এর স্বীকৃত উত্তরটি শুরু করার জন্য ভাল জায়গা)।

** এটি নির্দিষ্ট ওআর / এম সফ্টওয়্যারটির সাথে কিছুটা ঘোলাটে হয়ে যায় যেখানে আপনাকে 'সেভ' পদ্ধতিতে অবিচ্ছিন্ন বেস থেকে উত্তরাধিকারী হতে বাধ্য করা হয়।

Answer 2

আমি আসলে সম্প্রতি তথ্য থেকে বস্তুগুলি পৃথক করতে কিছু কোড পুনরায় কাজ করেছি। কারণটি হ'ল ডেটা পৃথক পরিষেবার মাধ্যমে প্রাপ্ত হয় এবং পুরো বস্তুটি পিছনে পিছনে পাস করার পরিবর্তে এবং সার্ভারে বৈধতা সংক্রান্ত ত্রুটিগুলি মোকাবেলা করার পরিবর্তে কেবল কাঁচা ডেটা সার্ভারে / থেকে পাস করা অনেক সহজ।

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

Answer 3

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

সুতরাং, আমি নিজেকে এই কংক্রিটের ক্ষেত্রে এটি জিজ্ঞাসা করব: গ্রাহককে কীভাবে নিজেকে বাঁচাতে হবে তা জানতে হবে?

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

গ্রাহক। আপগ্রেড ওয়ারেন্টি () বা কাস্টোমার.প্রোমোটটোপ্রেফার্ডড () সহ স্নোআরফাসের উদাহরণ হিসাবে, তারা গ্রাহকসেভ () এর চেয়ে স্পষ্টতই আরও বেশি যুক্তিযুক্ত যুক্তিযুক্ত। এটির জন্য বিভিন্ন পন্থা রয়েছে, তবে আবার যদি আপনি নিজেকে জিজ্ঞাসা করেন যে কোনও গ্রাহক তার ওয়্যারেন্টি আপগ্রেড করতে সক্ষম হবেন বলে মনে করা হচ্ছে, আপনি কীভাবে তাকান তার উপর নির্ভর করে উত্তরটি হ্যাঁ বা না উভয়ই হতে পারে:

• হ্যাঁ: একজন গ্রাহক অবশ্যই তার ওয়্যারেন্টি আপগ্রেড করতে পারেন
• না: কোনও গ্রাহক আপগ্রেড করার জন্য বলতে পারে, তবে আপগ্রেড অন্য কারও দ্বারা করা হয়েছে

আপনার মূল প্রশ্নে ফিরে যান; কোন উপায়ে বোঝা যায় সম্ভবত আপনি কাকে জিজ্ঞাসা করছেন এবং তাদের পছন্দের পদ্ধতির উপর নির্ভর করবে তবে সবচেয়ে গুরুত্বপূর্ণ বিষয় সম্ভবত এটি করার একটি উপায়কে আঁকড়ে রাখা।

যদিও আমার অভিজ্ঞতায় ডেটা আলাদা করা এবং (ব্যবসায়) যুক্তি একটি সহজ আর্কিটেকচারের জন্য তৈরি করে, যদিও এটি উত্তেজনাপূর্ণ নয়।

Answer 4

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

বিস্তৃত অর্থে, সত্তা যদি ডেটা স্ট্রাকচারের মতো আরও বেশি কাজ করে তবে তাদের আচরণ করা উচিত নয়, তবে যদি তাদের আচরণ থাকে তবে সেগুলি ডেটা কাঠামোর মতো ব্যবহার করা উচিত নয়। উদাহরণ:

তথ্য কাঠামো:

class CustomerController
{
    public int MostRecentOrderLines(Customer customer)
    {
        var o = (from order in customer.Orders
                orderby order.OrderDate desc
                select order).First();
        return o.OrderLines.ToList().Count;
    }
}

অ-ডেটা স্ট্রাকচার:

class Customer
{
    public int MostRecentOrderLines()
    {
        // ... same ...
    }
}

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

সুতরাং আপনি কি চান আপনার সত্তাগুলি ডেটা স্ট্রাকচার বা পরিষেবা হয়ে উঠুক? ধারাবাহিকতার জন্য, এটির সাথে থাকা ভাল মনে হয়। পূর্ববর্তী ক্ষেত্রে, আপনার "পরিষেবা" টাইপ যুক্তি যুক্ত করুন কোথাও, সত্তায় নয়।

Answer 5

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

আমি তাদের উত্থাপিত তথ্যগুলি সংক্ষেপে জানার চেষ্টা করব:

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

• কোনও বু আইজের কোড এবং কার্যকারিতা বোঝা সহজ।

• নকশায় কম জটিলতা

আমি তাদের বলছি তারা অলস এবং আমি এটি এটিকে তৈরি করব:

• হ্যাঁ ব্যবসায়িক ক্লাসগুলি জিনিসগুলিকে উপস্থাপন করে, তাই এটি ডেটা ধারণ করে। তবে নিজেকে বাঁচানো, এমনকি অনুলিপি করা ভুল মনে হয়। আপনি আরএল করতে পারবেন না।

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

• ডেটা অব্যাহত রাখতে সক্ষম একটি বস্তুর দ্বারা, সেই অবজেক্টটি একটি ডাটাবেস সংযোগ রাখতে পারে এবং সমস্ত ডাটাবেস ট্র্যাফিক সেই বস্তুটিতে নির্দেশিত হয়। (মূলত এটিতে ডেটা অ্যাক্সেসের স্তরটি থাকে) অন্যথায় সমস্ত ব্যবসায়িক অবজেক্টের একটি সংযোগ রাখতে হবে। (যা জটিলতা যোগ করে)

ওয়েল এক বা অন্য উপায়, আমি একজন শিক্ষক জিজ্ঞাসা করতে যাচ্ছি। আমি যখন এটি সম্পন্ন করেছি, আপনি চাইলে আমি তার উত্তর এখানে পোস্ট করব। ;)

সম্পাদনা:

আমি এই প্রকল্পটি একটি বইয়ের দোকান সম্পর্কে উল্লেখ করতে ভুলে গেছি।

Comments

আপনার সহপাঠীরা ঠিক বলেছেন, তারা যুক্তিযুক্ত অন্যান্য ফর্ম (এই ক্ষেত্রে, স্থাপত্য বা জেদী যুক্তি) এর সাথে ব্যবসায়িক লজিককে বিভ্রান্ত করছে except

— স্টিভেন এভার্স

Answer 6

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

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

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

সিআরইউডি অ্যাপ্লিকেশনটিতে তখন ডেটা প্রথম শ্রেণির নাগরিক তাই "" সংরক্ষণ "সম্পূর্ণ উপযুক্ত।

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

Answer 7

আমি কিছুক্ষণ ধরে একই প্রশ্নে ঝাঁপিয়ে পড়েছি - আমি মনে করি ডেটা উপাদান এবং যুক্তি উপাদানটি পৃথক হওয়া উচিত। আমি এটি বিশ্বাস করি কারণ এটি আপনাকে অর্থ সরবরাহ করে এমন ডেটার ইন্টারফেস হিসাবে ব্যবসায়িক যুক্তি সম্পর্কিত হিসাবে সঠিক মনের ফ্রেমে নিয়ে যায়।

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

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