ডাটাবেস সামগ্রীর উপর নির্ভর করে এমন ডোমেন মডেল নিয়মগুলি কোথায় বৈধতা দেবে?


10

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

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

এই দৃশ্যে, প্রতিটি ক্ষেত্রটি সঠিকভাবে পূরণ হয়েছে তা যাচাই করার জন্য আপনার মতে সবচেয়ে উপযুক্ত জায়গাটি কী? আমার কাছে বর্তমানে দুটি প্রধান পদ্ধতির কথা মনে আছে:

বিকল্প # 1: ডোমেন মডেলটিতে বৈধতা দিন

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

পেশাদাররা:

  • ক্ষেত্রগুলির বিরুদ্ধে দৃ protection় সুরক্ষা দুর্ঘটনাক্রমে মান নির্ধারণ করা হয়েছে যা বৈধকরণ বিধি লঙ্ঘন করে

কনস:

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

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

বিকল্প # 2: একটি পরিষেবাদীতে বৈধতা দিন

যাচাইয়ের বিধিটি নিশ্চিত করে এমন একটি পরিষেবার মাধ্যমে ক্ষেত্রের মান নির্ধারণের জন্য সমস্ত প্রচেষ্টা চেষ্টা করে দেখুন। যদি বৈধকরণের নিয়ম লঙ্ঘিত হয় তবে একটি বৈধকরণের ধারণাটি নিক্ষেপ করুন।

অবশ্যই, পূর্বে ডিবিতে স্থির থাকা ফিল্ড অবজেক্ট তৈরি করার সময় ডেটা অ্যাক্সেস লেয়ার পরিষেবাটি ব্যবহার করবে না

পেশাদাররা:

  • "আপনার ডোমেন মডেলগুলিতে পরিষেবা / সংগ্রহশালা ইনজেক্ট করবেন না" - চিন্তাভাবনা লঙ্ঘন করে না।

  • ক্ষেত্রটি অব্যাহত রাখার সময় বর্তমান বৈধকরণ বিধিটি বজায় রাখার দরকার নেই। পরিষেবাটি কেবলমাত্র ক্ষেত্রের জন্য বর্তমান বৈধকরণ বিধিটি সন্ধান করতে পারে; ইতিহাসের ডেটা দেখার সময়, ক্ষেত্রের মান পরিবর্তন করা হবে না।

কনস:

  • কোনও গ্যারান্টি নেই যে ক্ষেত্রের মান সেট করতে পরিষেবাটি ব্যবহার করা উচিত এমন সমস্ত যুক্তি আসলে তা করে। আমি এটিকে একটি বড় অসুবিধা হিসাবে দেখছি; এটি "লেগেছে যে কেউ" এই ফিল্ড.সেটভ্যালু (যেফিল্ড.সেটভ্যালু ()) লিখছেন এবং এই ফিল্ডের বৈধতা বিধি লঙ্ঘন হতে পারে কেউ বুদ্ধিমান না হয়ে হতে পারে। ডেটা অ্যাক্সেস লেয়ার ফিল্ডটি অবিরত করার সময় ক্ষেত্রটির মান বৈধকরণের নিয়মের সাথে মেলে কিনা তা নিশ্চিত করে এই সম্ভাব্যতা হ্রাস করা যেতে পারে।

আমি বর্তমানে অপশন # 1 এর চেয়ে অপশন # 2 এর চেয়ে বেশি পছন্দ করি, মূলত কারণ আমি এটিকে ব্যবসায়িক যুক্তি হিসাবে দেখি এবং মনে করি যে বিকল্প # 2 সিস্টেমে খারাপ ডেটা প্রবর্তনের আরও বেশি ঝুঁকি রয়েছে। আপনি কোন বিকল্পটি পছন্দ করেন, বা বর্ণিত দুটি বিকল্পের চেয়ে আরও ভাল কোনও ডিজাইন রয়েছে যা এই দৃশ্যের সাথে খাপ খায়?

সম্পাদনা করুন (বৈধতার জটিলতা)

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

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


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

উত্তর:


4

বৈধতা কতটা জটিল? প্রায়শই বৈধতার ক্ষেত্রে ক্ষেত্র এবং বা ব্যবসায়ের নিয়মের সংমিশ্রণ প্রয়োজন যা ক্ষেত্রগুলিতে নির্ভুলভাবে মূল্যায়নের জন্য নির্ভর করে।

বৈধকরণগুলি আরও জটিল, শক্ত এবং কম পারফরম্যান্ট বিকল্প # 2।

অবশ্যই ডেটা স্তরটি অধ্যবসায়ের সময়ে বৈধতা পরিষেবাটি প্রার্থনা করতে পারে। নিয়ম পরিবর্তনের কারণে ডেটাটি একটি অবৈধ অবস্থায় রয়েছে এমন এই বেহাল পরিস্থিতিকে সহায়তা করতে পারে।

মন্তব্য করার মতো অন্যান্য আইটেমটি হ'ল কোনও ধরণের Qa চক্র ছাড়াই বৈধতা নিয়মের পরিবর্তনের ক্ষমতা। তবে এটি একটি আলাদা থ্রেডের বিষয়।

উপরের তথ্য প্রদত্ত, বিকল্প 1 বৈধতা এবং দৃistence়তা পৃথক করে আপনি শৃঙ্খলা বজায় রেখে ধরে নিচ্ছেন এটি সবচেয়ে নমনীয় বলে মনে হচ্ছে।


0

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

অ্যাপ্লিকেশন পরিষেবা স্তরটি रिपোজিটরি এবং ব্যবসার যুক্তিযুক্ত ডোমেন মডেলের সাথে ইন্টারঅ্যাক্ট করার অনুমতি দেয়। সুতরাং আপনার মতো কিছু থাকতে পারে:

FieldUpdateService >> updateField(fieldId, newValue)
  List<FieldRule> rules = this.rulesRepository.findRulesFor(fieldId)
  Field field = this.fieldRepository.find(fieldId)
  try 
    field.updateValue(rules,newValue)
    fieldRepository.save(field)
  catch 
    // manage error

যদি আপনার কোনও ফিল্ড এবং তার ফিল্ডআরুলসের মধ্যে সম্পর্ক থাকে এবং জাভাতে হাইবারনেটের মতো একটি ওআরএম ব্যবহার করেন তবে আপনি কেবল তা করতে পারবেন:

FieldUpdateService >> updateField(fieldId, newValue)
  Field field = this.fieldRepository.find(fieldId)
  try 
    field.updateValue(newValue)
    fieldRepository.save(field)
  catch 
    // manage error

Field >> updateValue(newValue)
  for rule in rules
     if !rule.isValid(newValue)
        throw ValueNotAllowedException
  this.value = newvalue

কারণ ওআরএম আপনার জিজ্ঞাসা করা বস্তুর গ্রাফটি কোয়েস্ট এবং ইনস্ট্যান্ট করে দেয়।

যে কেউ করতে পারে তা সম্পর্কে আপনার সন্দেহ সম্পর্কিত

এইফিল্ড.সেটওয়ালিউ (যেফিল্ড.জেটভ্যালু ()) "এবং এই ফিল্ডের বৈধতা বিধি লঙ্ঘন হতে পারে কেউ বুদ্ধিমান না হয়ে

কেউ এও লিখতে পারেন: FieldRule সর্বদাReturnTrueRule = new FieldRule {isValid (newValue) {সত্য প্রত্যাবর্তন; }} Field.updateValue ("uncheckedValue", সর্বদাReturnTrueRule) এটি একটি অস্পষ্ট উদাহরণ তবে যা বলতে ইচ্ছুক তা হ'ল কোনও কিছুই আপনাকে কোডের খারাপ ব্যবহার থেকে রক্ষা করে না। সম্ভবত ভাল ডকুমেন্টেশন এবং মুখোমুখি মুখোমুখি। আমি মনে করি কোনও কিছুই আপনাকে কোডের খারাপ ব্যবহার থেকে রক্ষা করে না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.