একজন "কর্মচারী" শ্রেণি কীভাবে ডিজাইন করা উচিত?

আমি কর্মীদের পরিচালনার জন্য একটি প্রোগ্রাম তৈরি করার চেষ্টা করছি। Employeeক্লাসটি কীভাবে ডিজাইন করা যায় তা আমি বুঝতে পারি না । আমার লক্ষ্য হ'ল একটি Employeeঅবজেক্ট ব্যবহার করে ডেটাবেজে কর্মচারী ডেটা তৈরি এবং পরিচালনা করতে সক্ষম হব ।

আমি যে প্রাথমিক বাস্তবায়নটি ভেবেছিলাম, এটি ছিল এটিই সাধারণ:

class Employee
{
    // Employee data (let's say, dozens of properties).

    Employee() {}
    Create() {}
    Update() {}
    Delete() {}
}

এই বাস্তবায়নটি ব্যবহার করে, আমি বেশ কয়েকটি সমস্যার মুখোমুখি হয়েছি।

IDএকজন কর্মী তাই যদি আমি একটি নতুন কর্মচারী বর্ণনা জন্য অবজেক্ট ব্যবহার, ডাটাবেজ দেওয়া হয়, কোন হতে হবে IDএখনো সংরক্ষণ করা, যখন একটি বস্তু একটি বিদ্যমান কর্মচারী প্রতিনিধিত্বমূলক হবে একটি আছে ID। সুতরাং আমার একটি সম্পত্তি রয়েছে যা কখনও কখনও অবজেক্টটি বর্ণনা করে এবং কখনও কখনও তা করে না (যা নির্দেশ করে যে আমরা এসআরপি লঙ্ঘন করেছি ? যেহেতু আমরা নতুন এবং বিদ্যমান কর্মীদের প্রতিনিধিত্ব করার জন্য একই শ্রেণিটি ব্যবহার করি ...)।
Createপদ্ধতি, ডাটাবেজ উপর একজন কর্মী তৈরি করতে অনুমিত যখন হয় Updateএবং Deleteএকটি বিদ্যমান কর্মচারী (আবার, কাজ করার জন্য অনুমিত হয় SRP ...)।
'তৈরি' পদ্ধতিতে কোন পরামিতি থাকা উচিত? সমস্ত কর্মচারী ডেটা বা কোনও Employeeবস্তুর জন্য কয়েক ডজন পরামিতি ?
ক্লাস কি অপরিবর্তনীয় হওয়া উচিত?
কীভাবে Updateকাজ করবে ? এটি কি সম্পত্তি গ্রহণ করবে এবং ডাটাবেস আপডেট করবে? অথবা সম্ভবত এটি দুটি অবজেক্ট গ্রহণ করবে - একটি "পুরাতন" একটি এবং "নতুন" একটি, এবং তাদের মধ্যে পার্থক্য সহ ডাটাবেস আপডেট করবে? (আমি মনে করি উত্তরটির সাথে ক্লাসের পরিবর্তনের বিষয়ে জবাব দিতে হবে)।
কনস্ট্রাক্টরের দায়িত্ব কী হবে? এটি প্যারামিটারগুলির কী হবে? এটি কোনও idপরামিতি ব্যবহার করে ডেটাবেস থেকে কর্মচারী ডেটা আনবে এবং সেগুলি বৈশিষ্ট্যগুলিকে জনবসত করবে?

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

দয়া করে লক্ষ্য করুন যে আমি এই জাতীয় মতামত চাই না, কেবলমাত্র এই জাতীয় ঘন ব্যবহৃত ক্লাসটি সাধারণত কীভাবে ডিজাইন করা হয় তা বোঝার জন্য।

object-oriented class-design class

— Sipo
সূত্র

আপনার এসআরপি-র লঙ্ঘন হ'ল আপনার একটি শ্রেণি রয়েছে যা সত্তার প্রতিনিধিত্ব করে এবং সিআরইউডি যুক্তির জন্য দায়বদ্ধ। আপনি যদি এটি আলাদা করেন তবে সেই CRUD ক্রিয়াকলাপ এবং সত্তা কাঠামোটি বিভিন্ন শ্রেণি হবে, তবে 1. এবং 2. এসআরপি ভাঙ্গবেন না। ৩.Employee বিমূর্ততা প্রদানের জন্য একটি অবজেক্ট গ্রহণ করা উচিত , প্রশ্নসমূহ ৪ এবং ৫. সাধারণত অপ্রয়োজনীয় হয়, আপনার প্রয়োজনের উপর নির্ভর করে এবং যদি আপনি কাঠামো এবং সিআরইউডি অপারেশনগুলিকে দুটি শ্রেণিতে বিভক্ত করেন, তবে এটি বেশ স্পষ্টভাবে জানা যায় যে, নির্মাণকারীর Employeeডেটা আনতে পারে না ডিবি থেকে আর, যাতে উত্তর 6.

— অ্যান্ডি

@ ডেভিডপ্যাকার - ধন্যবাদ আপনি একটি উত্তর দিতে পারেন?

— সিপো

আমি পুনরাবৃত্তি করব না , আপনার সিটিটি ডাটাবেসে পৌঁছানোর দরকার নেই। ডাটাবেসে কোডটি এইভাবে শক্তভাবে করা কাপলকে পরীক্ষা করে thingsশ্বরকে ভয়ঙ্কর করে তোলে (এমনকি ম্যানুয়াল পরীক্ষাও শক্ত হয়ে যায়)। সংগ্রহস্থলের প্যাটার্নটি দেখুন। এক সেকেন্ডের জন্য এটি সম্পর্কে চিন্তা করুন, আপনি কি Updateকোনও কর্মচারী, বা আপনি কোনও কর্মচারী রেকর্ড আপডেট করেন? আপনি Employee.Delete(), না একটি Boss.Fire(employee)?

— রাবারডাক

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

— মিঃ কোচিজ

উত্তর:

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

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

সংক্ষেপে, একটি সক্রিয় রেকর্ড হ'ল একটি অবজেক্ট, যা:

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

আপনি আপনার বর্তমান ডিজাইনটি নিয়ে বেশ কয়েকটি সমস্যা সমাধান করেছেন এবং আপনার নকশার মূল সমস্যাটি শেষ, 6th ষ্ঠ, পয়েন্টে বর্ণিত হয়েছে (শেষ কিন্তু কমপক্ষে নয়, আমার ধারণা)। যখন আপনার একটি ক্লাস থাকে যার জন্য আপনি কনস্ট্রাক্টর ডিজাইন করছেন এবং আপনি জানেন না যে কন্সট্রাক্টরের কী করা উচিত, ক্লাসটি সম্ভবত কিছু ভুল করছে। আপনার ক্ষেত্রে এটি ঘটেছে।

তবে সত্তার প্রতিনিধিত্ব এবং সিআরইউডি যুক্তিযুক্তিকে দুটি (বা আরও) শ্রেণিতে বিভক্ত করে নকশাটি ঠিক করা আসলে বেশ সহজ।

আপনার ডিজাইনটি এখন দেখতে দেখতে এটি:

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

_{বাহ, ক্লাসটি বিশাল মনে হচ্ছে।}

এটি প্রস্তাবিত সমাধান হবে:

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

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

একটি মডিউল পরিবর্তনের এক এবং একমাত্র কারণ থাকতে হবে।

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

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

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

এটিকে (কমপক্ষে) দুটি শ্রেণিতে বিভক্ত করার আরেকটি দুর্দান্ত বিষয় হ'ল এখন Employeeক্লাসটি স্পষ্টভাবে তার নিজস্ব ডেটা পরিচালনা করতে পারে এবং এটি খুব ভালভাবে করতে পারে, কারণ এটি অন্যান্য কঠিন জিনিসের যত্ন নেওয়ার প্রয়োজন হয় না।

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

প্রশ্ন 4: মোটেই উত্তর দেওয়া যায় না, সাধারণত হয় না, কারণ উত্তরটি আপনার প্রয়োজনের উপর নির্ভর করে depends

প্রশ্ন 5: এখন যেহেতু আপনি দুটি স্ফীত বর্গ পৃথক, আপনি সরাসরি একাধিক আপডেটের পদ্ধতি থাকতে পারে Employeeবর্গ, মত changeUsername, markAsDeceased, ডাটা নিপূণভাবে করবে Employeeবর্গ শুধুমাত্র RAM- র মধ্যে এবং তারপর আপনি যেমন একটি পদ্ধতি প্রবর্তন পারে registerDirtyথেকে সংগ্রহস্থল শ্রেণিতে কাজের প্যাটার্নের ইউনিট , যার মাধ্যমে আপনি সংগ্রহস্থলটিকে জানাতে পারবেন যে এই বস্তুটির বৈশিষ্ট্যগুলি পরিবর্তিত হয়েছে এবং commitপদ্ধতিটি কল করার পরে আপনাকে আপডেট করতে হবে ।

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

প্রশ্ন 3: আপনি যদি ইউনিট অফ ওয়ার্কের প্যাটার্নটি নিয়ে যাওয়ার সিদ্ধান্ত নেন createতবে এখন পদ্ধতিটি হবে registerNew। আপনি যদি না করেন তবে আমি সম্ভবত এটির saveপরিবর্তে কল করব । একটি সংগ্রহস্থলের লক্ষ্য হ'ল ডোমেন এবং ডেটা স্তরগুলির মধ্যে বিমূর্ততা সরবরাহ করা, যার কারণে আমি আপনাকে সুপারিশ করব যে এই পদ্ধতিটি (এটি হোক registerNewবা save) Employeeবস্তুটি গ্রহণ করে এবং এটি রেপোজিটরি ইন্টারফেস প্রয়োগকারী শ্রেণীর উপর নির্ভর করে, যা গুণাবলী তারা সত্তা থেকে সরিয়ে নেওয়ার সিদ্ধান্ত নেয়। একটি সম্পূর্ণ অবজেক্ট পাস করা ভাল তাই আপনার অনেকগুলি alচ্ছিক পরামিতি থাকতে হবে না।

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

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

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

গুরুত্বপূর্ণ তথ্য

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

— অ্যান্ডি
সূত্র

হুম আমার উত্তর হিসাবে একই, তবে 'ধারালো' শেডগুলিতে রাখে

— ইভান

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

— অ্যান্ডি

সুন্দর এবং বিস্তৃত উত্তর। উদ্বেগের বিচ্ছিন্নতা দিয়ে মাথায় পেরেক আঘাত করে। এবং আমি এই সতর্কতাটি পছন্দ করি যা একটি নিখুঁত জটিল নকশা এবং একটি সুন্দর আপোষের মধ্যে গুরুত্বপূর্ণ পছন্দটিকে নির্দেশ করে।

— ক্রিস্টোফ

সত্য, আপনার উত্তরটি সর্বোত্তম

— এভান

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

— সুসান্থা

প্রথমে ধারণাগত কর্মচারীর বৈশিষ্ট্যযুক্ত একটি কর্মচারী কাঠামো তৈরি করুন।

তারপরে টেবিল কাঠামোর সাথে মিলে একটি ডাটাবেস তৈরি করুন, উদাহরণস্বরূপ mssql বলুন

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

তারপরে সিআরইউডি ক্রিয়াকলাপ প্রকাশ করে একটি আইম্প্লোয়েআরপিও ইন্টারফেস তৈরি করুন

তারপরে IEmployeeRepo এর নির্মাণ প্যারামিটার সহ আপনার কর্মচারী কাঠামোটিকে একটি শ্রেণিতে প্রসারিত করুন। আপনার প্রয়োজনীয় বিভিন্ন সেভ / মুছুন ইত্যাদি পদ্ধতি যুক্ত করুন এবং সেগুলি বাস্তবায়নের জন্য ইনজেকশন করা কর্মচারী রেপো ব্যবহার করুন।

যখন এটি আইডিতে সংকেত দেয় আমি আপনাকে পরামর্শ দিই যে আপনি একটি জিইউডি ব্যবহার করুন যা কনস্ট্রাক্টরের কোডের মাধ্যমে তৈরি করা যেতে পারে।

বিদ্যমান বস্তুগুলির সাথে কাজ করার জন্য আপনার কোড তাদের আপডেট পদ্ধতিটি কল করার আগে তাদের সংগ্রহস্থলের মাধ্যমে ডাটাবেস থেকে পুনরুদ্ধার করতে পারে।

বিকল্পভাবে আপনি নীচের দিকে (তবে আমার বিবেচনায় উন্নত) অ্যানমিক ডোমেন অবজেক্ট মডেলটি বেছে নিতে পারেন যেখানে আপনি নিজের বস্তুতে CRUD পদ্ধতি যুক্ত করেন না এবং কেবলমাত্র আপডেট / সংরক্ষণ / মুছে ফেলার জন্য অবজেক্টটিকে রেপোতে পাস করতে পারেন simply

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

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

***** উদাহরণ কোড

public class Employee
{
    public string Id { get; set; }

    public string Name { get; set; }

    private IEmployeeRepo repo;

    //with the OOP approach you want the save method to be on the Employee Object
    //so you inject the IEmployeeRepo in the Employee constructor
    public Employee(IEmployeeRepo repo)
    {
        this.repo = repo;
        this.Id = Guid.NewGuid().ToString();
    }

    public bool Save()
    {
        return repo.Save(this);
    }
}

public interface IEmployeeRepo
{
    bool Save(Employee employee);

    Employee Get(string employeeId);
}

public class EmployeeRepoSql : IEmployeeRepo
{
    public Employee Get(string employeeId)
    {
        var sql = "Select * from Employee where Id=@Id";
        //more db code goes here
        Employee employee = new Employee(this);
        //populate object from datareader
        employee.Id = datareader["Id"].ToString();

    }

    public bool Save(Employee employee)
    {
        var sql = "Insert into Employee (....";
        //db logic
    }
}

public class MyADMProgram
{
    public void Main(string id)
    {
        //with ADM don't inject the repo into employee, just use it in your program
        IEmployeeRepo repo = new EmployeeRepoSql();
        var emp = repo.Get(id);

        //do business logic
        emp.Name = TextBoxNewName.Text;

        //save to DB
        repo.Save(emp);

    }
}

— ইওয়ান
সূত্র

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

— অ্যান্ডি

ঠিক এই ক্ষেত্রে, রেপো হ'ল পরিষেবা এবং ফাংশনগুলি CRUD অপারেশন।

— ইভান

@ ডেভিডপ্যাকার আপনি কি অ্যানমিক ডোমেন মডেলটি একটি ভাল জিনিস বলছেন?

— candied_orange

@ ক্যান্ডিওড অ্যারেঞ্জ আমি মন্তব্যে আমার মতামত প্রকাশ করি নি, তবে না, আপনি যদি নিজের প্রয়োগটিকে স্তরগুলিতে ডাইভিং করার সিদ্ধান্ত নেন তবে যেখানে একটি স্তর কেবল ব্যবসায়ের যুক্তির জন্য দায়ী, আমি মিঃ ফাউলারের সাথে আছি যে একটি রক্তাল্পতা ডোমেন মডেল আসলে এটি একটি অ্যান্টি-প্যাটার্ন। আমার কেন UserUpdateএকটি changeUsername(User user, string newUsername)পদ্ধতির সাথে পরিষেবা প্রয়োজন , যখন আমি কেবল পাশাপাশি changeUsernameক্লাসে পদ্ধতিটি যুক্ত করতে পারি User। তার জন্য একটি পরিষেবা তৈরি করা বুদ্ধিমানের কাজ।

— অ্যান্ডি

আমি মনে করি এই ক্ষেত্রে কেবলমাত্র মডেলটিতে সিআরইউডি যুক্তি যুক্ত করার জন্য রেপো ইনজেকশন করা অনুকূল নয়।

— ইভান

আপনার নকশা পর্যালোচনা

আপনার Employeeবাস্তবে ডাটাবেসে অবিচ্ছিন্নভাবে পরিচালিত কোনও অবজেক্টের জন্য এক ধরণের প্রক্সি।

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

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

আপনাকে অবজেক্টটির জন্য একটি স্থিতি পরিচালনা করতে হবে। উদাহরণ স্বরূপ:

যখন কোনও কর্মচারী তৈরি বা ডেটা পুনরুদ্ধারের মাধ্যমে কোনও ডিবি অবজেক্টের সাথে এখনও যুক্ত না হয়ে থাকেন, আপনি আপডেট বা মুছতে সক্ষম হবেন না
ডাটাবেসের সাথে সিঙ্কে অবজেক্টের কর্মচারী ডেটা নাকি কোনও পরিবর্তন হয়েছে?

এটিকে মনে রেখে আমরা এই বিকল্পগুলি বেছে নিতে পারি:

class Employee
{
    ...
    Employee () {}       // Initialize an empty Employee
    Load(IDType ID) {}   // Load employee with known ID from the database
    bool Create() {}     // Create an new employee an set its ID 
    bool Update() {}     // Update the employee (can ID be changed?)
    bool Delete() {}     // Delete the employee (and reset ID because there's no corresponding ID. 
    bool isClean () {}   // true if ID empty or if all properties match database
}

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

তোমার প্রশ্নগুলো

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

আর একটি নকশা হ'ল পরিবর্তনযোগ্য ক্ষেত্রগুলিকে অন্য কোনও অবজেক্টে রাখা হবে যা কেবল তখন ক্ষেত্রগুলিতে অ্যাক্সেস করার প্রয়োজন হলে লোড হবে।

আপনি কমান্ড প্যাটার্ন ব্যবহার করে কর্মচারীর উপর ডেটাবেস লেনদেন বাস্তবায়ন করতে পারেন । এই জাতীয় ডিজাইনটি আপনার ব্যবসায়িক বস্তু (কর্মচারী) এবং আপনার অন্তর্নিহিত ডাটাবেস সিস্টেমের মধ্যে ডেটাবেস নির্দিষ্ট আইডিয়াম এবং এপিআই পৃথক করে দ্বিগুণ কমিয়ে আনবে ease
আমি এতে কয়েক ডজন প্যারামিটার যুক্ত করব না Create(), কারণ ব্যবসায়ের অবজেক্টগুলি এই সমস্ত বজায় রাখা খুব কঠিন করে তুলতে পারে। এবং কোডটি অপঠনযোগ্য হয়ে উঠবে। আপনার এখানে দুটি পছন্দ আছে: হয় প্যারামিটারগুলির একটি সংক্ষিপ্ত সেট পাস (4 টির বেশি নয়) যা ডেটাবেজে কোনও কর্মী তৈরি করার জন্য প্রয়োজনীয় এবং আপডেটের মাধ্যমে অবশিষ্ট পরিবর্তনগুলি সম্পাদন করতে পারেন, বা আপনি কোনও বস্তু পাস করেন। উপায় দ্বারা, আপনার নকশা মধ্যে আমি বুঝতে পারি যে আপনি ইতিমধ্যে মনোনীত করেছি: my_employee.Create()।
ক্লাস কি অপরিবর্তনীয় হওয়া উচিত? উপরে আলোচনা দেখুন: আপনার মূল নকশা নং। আমি অপরিবর্তনীয় আইডি বেছে নেব তবে কোনও অপরিবর্তনীয় কর্মচারী নয়। একজন কর্মী বাস্তব জীবনে বিকশিত হয় (নতুন কাজের অবস্থান, নতুন ঠিকানা, নতুন বিবাহ সংক্রান্ত পরিস্থিতি, এমনকি নতুন নাম ...)। আমি মনে করি এই বাস্তবতাকে মাথায় রেখে কমপক্ষে ব্যবসায়ের যুক্তিযুক্ত স্তরে কাজ করা সহজ এবং প্রাকৃতিক হবে।
আপনি যদি পুরানো / নতুন পদ্ধতির জন্য পছন্দ করতে পারেন তবে পছন্দসই পরিবর্তনগুলি ধরে রাখার জন্য আপডেটের জন্য একটি আদেশ এবং (জিইউআই?) এর জন্য একটি পৃথক অবজেক্ট ব্যবহার করার বিষয়টি বিবেচনা করেন। অন্য সমস্ত ক্ষেত্রে, আমি একটি পরিবর্তনীয় অবজেক্ট আপডেট করার বিকল্প বেছে নেব। মনোযোগ দিন: আপডেটটি ডাটাবেস কোডটিকে ট্রিগার করতে পারে যাতে কোনও আপডেটের পরে অবশ্যই ডিবিটির সাথে সামঞ্জস্য করার বিষয়টি নিশ্চিত করা উচিত।
আমি মনে করি যে কনস্ট্রাক্টরে ডিবি থেকে কোনও কর্মচারী আনা ভাল ধারণা নয়, কারণ আনতে ভুল হতে পারে, এবং অনেক ভাষায়, ব্যর্থ নির্মাণের সাথে লড়াই করা কঠিন। কনস্ট্রাক্টরের উচিত বস্তু (বিশেষত আইডি) এবং তার স্থিতি আরম্ভ করা উচিত।

— ক্রিস্টোফ
সূত্র