এনামগুলিতে অবিচ্ছেদ্য শনাক্তকারীদের ম্যাপিংয়ের ত্রুটিগুলি কী কী?

16

আমি এই জাতীয় শনাক্তকারীদের জন্য কাস্টম ধরণের তৈরি সম্পর্কে ভাবছিলাম:

public enum CustomerId : int { /* intentionally empty */ }
public enum OrderId : int { }
public enum ProductId : int { }

এটির জন্য আমার প্রাথমিক প্রেরণা হ'ল যে ধরণের বাগ আপনি যেখানে ভুলবশত অর্ডার আইটেমটিটেলইড প্রত্যাশা করে এমন কোনও ফাংশনটিতে অর্ডার আইটেম আইড পাস করে prevent

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

এমভিসি রাউটিংটি দুর্দান্ত কাজ করে
জেএসওএন সিরিয়ালাইজেশন সূক্ষ্মভাবে কাজ করে
প্রতিটি ওআরএম আমি সূক্ষ্ম কাজ সম্পর্কে ভাবতে পারি

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

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

সুতরাং আমার প্রশ্ন, আমি কি অনুপস্থিত? এটি সম্ভবত একটি খারাপ ধারণা, তবে কেন?

c#

— default.kramer
সূত্র

এনামগুলি কখন কোনও কোডের গন্ধ হয় না?

— gnat

3

এটিকে "মাইক্রোটাইপিং" বলা হয়, আপনি চারপাশে গুগল করতে পারেন (যেমন এটি জাভার জন্য, বিশদগুলি ভিন্ন, তবে প্রেরণা একই)

— qbd

আমি দুটি আংশিক উত্তর লিখেছি এবং সেগুলি মুছে ফেলেছি কারণ আমি বুঝতে পেরেছিলাম যে আমি এই ভুল সম্পর্কে ভাবছিলাম। আমি আপনার সাথে একমত যে "এটি সম্ভবত একটি খারাপ ধারণা, তবে কেন?"

— ব্যবহারকারী2023861

7

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

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

আপনি কার্যকরী সি # নিবন্ধে এটি বাস্তবায়নের বিষয়ে পড়তে পারেন : আদিম আবেশ ।

— লুকা লানস্কে
সূত্র

1

আমি আপনাকে বলতে চাই যে প্রায় প্রতিটি ক্লাসে নয় বরং স্ট্রাক্ট

— জেকেতে

ভালো মন্তব্য, আমি উত্তরটি কিছুটা আপডেট করেছি।

— লুকা লানস্কি

3

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

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

— JacquesB
সূত্র

1

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

— default.kramer

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

— জ্যাকবিবি

2

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

এটি কিভাবে কাজ করে তা আমি জানি না নেট কার্য সম্পাদন অনুযায়ী, যেমন এনাম মানগুলি বাক্সে প্রয়োজনীয় box OTOH কোড যা একটি ডাটাবেসের সাথে কাজ করে তা সম্ভবত I / O- আবদ্ধ এবং বক্সযুক্ত শনাক্তকারীরা কোনও বাধা হয়ে উঠবে না।

একটি নিখুঁত বিশ্বে শনাক্তকারীরা পরিবর্তনহীন এবং কেবলমাত্র সমতার জন্য তুলনীয় হবে; প্রকৃত বাইটগুলি একটি বাস্তবায়ন বিশদ হবে। সম্পর্কিত নয় এমন শনাক্তকারীদের কাছে বেমানান ধরনের রয়েছে যাতে আপনি ভুল করে অন্যের জন্য ব্যবহার করতে পারেন না। আপনার সমাধানটি কার্যত বিলটি ফিট করে।

— 9000
সূত্র

-1

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

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

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

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

আপনার পরামর্শের সাথে আপনি টাইপ সুরক্ষার চেয়ে আরও বেশি চান, আপনি মান সুরক্ষা চান এবং এটি মডেলিং ডোমেনের বাইরে, এটি একটি অপারেশনাল সমস্যা।

— মার্টিন মাট
সূত্র

1

না, এনটগুলিকে। নেট এ পূর্বনির্ধারিত হতে হবে না। এবং মুল বক্তব্যটি হ'ল কাস্টিং কদাচিৎ হয় না, যেমন public ActionResult GetCustomer(CustomerId custId)কোনও কাস্টের প্রয়োজন নেই - এমভিসি ফ্রেমওয়ার্কটি মান সরবরাহ করে।

— default.kramer

2

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

— কিবিডি

1

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

— মার্টিন মাট