আমাকে আপস করতে হবে: ডিআরওয়াই, না কমান্ড-কোয়েরি-বিচ্ছেদ?

Question

আমি সম্প্রতি এমন একটি পদ্ধতির পুনঃসংশোধন করছি যা কমান্ড এবং কোয়েরি পদ্ধতি উভয়ই ছিল।

এটি একটি কমান্ড পদ্ধতি এবং একটি কোয়েরি পদ্ধতিতে পৃথক করার পরে, আমি দেখতে পেলাম যে কোডটিতে এখন আমি একাধিক জায়গা পেয়েছি যেখানে আমি কমান্ডটি কল করছি তারপরে কোয়েরি থেকে মান পাওয়া যাচ্ছে, যা DRY নীতি লঙ্ঘনের মতো বলে মনে হচ্ছে।

তবে যদি আমি সেই সাধারণ কোডটি কোনও পদ্ধতিতে মোড়ক করতে পারি তবে সেই পদ্ধতিটি হ'ল কমান্ড এবং কোয়েরি। এটা কি গ্রহণযোগ্য?

Comments

ঠিক আছে, আমি জানতাম না যে সম্প্রদায়টি conকমত্যে রয়েছে এবং আমি এই বিষয়ে কোনও আলোচনা খুঁজে পাইনি।

— ক্রিস ওয়েলশ

একে আরও সাধারণভাবে CQRS google.com.au/…

— ড্যানিয়েল লিটল

@ ড্যানিয়েলিটল - না তা নয়। সিকিউএস এবং সিকিউআরএস আলাদা আলাদা বিষয়। সিকিউআরএস হ'ল অনেক বেশি জড়িত আর্কিটেকচারাল প্যাটার্ন যেখানে সিকিউএস ডিজাইন প্যাটার্নের চেয়ে বেশি এবং উপলব্ধি করা এবং বাস্তবায়ন করা আরও সহজ। কোডবেটার.com

— 2009/

@ এরিক ফানকেনবাশ আপনি ঠিক বলেছেন

— ড্যানিয়েল লিটল

Answer 1

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

QueryResult command()
{
   // do command stuff
   return query();
}

Answer 2

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

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

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

আমি মনে করি মোড়ক পদ্ধতি পুরোপুরি গ্রহণযোগ্য সমাধান এবং এটি চিত্রিত করতে, আসুন আপনার উদাহরণটি আরও একধাপ এগিয়ে নেওয়া যাক। আপনাকে যদি 1 এর পরিবর্তে 2 টি ক্যুরি চালাতে হয় এবং তারপরে কোনও কমান্ড অ্যাকশন করতে হয় তবে। সুতরাং আপনার 2 লাইনের কোডটি 6 বা 8 হবে one যদি কোনও একের সাথে অন্যের মধ্যে কিছু ডেটা বৈধতা / পরীক্ষা করা হয়, তবে এখন আপনার কোডের 15 লাইন রয়েছে। আপনি কি একাধিক ফাইলে 15 15 টি লাইন ছিটানোর পরিবর্তে এমন একটি মোড়ক তৈরির বিষয়ে দুবার ভাবেন?

Comments

আমি মনে করি একটি মোড়কের "একক নীতি" হ'ল কমান্ড এবং ক্যোয়ারির দরকার হয় এমন অন্যান্য পদ্ধতিগুলি DRY রাখা উচিত।

— ড্রুগানস

গুগল সিকিউআরএস: google.com.au/…

— ড্যানিয়েল লিটল

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

— ক্রিস ওয়েলশ

Answer 3

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

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

1. এর ফলাফলগুলির জন্য কোড কার্যকর করার প্রয়োজনীয়তা এড়ানো যায় না, কারণ এটি ছোট ইউনিটগুলি থেকে বৃহত প্রোগ্রামগুলি রচনা করার জন্য ভিত্তি।

2. এর প্রভাবগুলির জন্য কোড কার্যকর করার প্রয়োজনীয়তাও এড়ানো যায় না, কারণ গণিত এবং তাত্ত্বিক কম্পিউটার বিজ্ঞানের বাইরে প্রোগ্রাম চালানোর মূল্য আমাদের জন্য যা পর্যবেক্ষণযোগ্যভাবে করতে পারে তার উপর নির্ভর করে।

3. একই কোডে প্রভাব ফেলতে এবং ফলাফল আনার প্রয়োজনীয়তা এড়ানো যায় না, কারণ বাস্তবে, আমাদের কেবল একটি বা অন্য নয়, প্রভাব এবং রচনা উভয়ই প্রয়োজন।

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

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

Comments

জটিলতা হ্রাস করতে কখনও কখনও আপনার সংযুক্ত হওয়া এড়ানো প্রয়োজন। আপনার সিকিউআরএস একবার দেখে নেওয়া উচিত।

— ড্যানিয়েল লিটল

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

— পাইওন

@ লাভিনস্কি: বিশেষত সিকিউআরএসের বিষয়ে, ধারণামূলকভাবে সঠিক বিকল্প সমাধানটি হ'ল ১. ডেটা মডেলটি বুঝতে (কোনও পরিমাণ স্তর স্তর এটির জন্য প্রয়োজনীয়তা মুছে ফেলতে পারে না), ২. ডাটাবেস স্কিমাতে যতটা নির্ভুলতা থাকা যায় ততগুলি এনকোড করুন। (দুঃখের বিষয়, সর্বাধিক জনপ্রিয় আরডিবিএমএসই নোএসকিউএলগুলির উল্লেখ না করে সীমাবদ্ধ সমর্থন সরবরাহ করে, এটি এটিকে আরও বেশি ভুল বলে মনে করে My আমার বর্তমান গবেষণা

— এটির

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

— ড্যানিয়েল লিটল

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

— স্টিফান বিলিয়েট