যেখানে আমাদের ডোমেন মডেলের বৈধতা দেওয়া উচিত


38

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

public class Order
 {
    private readonly List<OrderLine> _lineItems;

    public virtual Customer Customer { get; private set; }
    public virtual DateTime OrderDate { get; private set; }
    public virtual decimal OrderTotal { get; private set; }

    public Order (Customer customer)
    {
        if (customer == null)
            throw new  ArgumentException("Customer name must be defined");

        Customer = customer;
        OrderDate = DateTime.Now;
        _lineItems = new List<LineItem>();
    }

    public void AddOderLine //....
    public IEnumerable<OrderLine> AddOderLine { get {return _lineItems;} }
}


public class OrderLine
{
    public virtual Order Order { get; set; }
    public virtual Product Product { get; set; }
    public virtual int Quantity { get; set; }
    public virtual decimal UnitPrice { get; set; }

    public OrderLine(Order order, int quantity, Product product)
    {
        if (order == null)
            throw new  ArgumentException("Order name must be defined");
        if (quantity <= 0)
            throw new  ArgumentException("Quantity must be greater than zero");
        if (product == null)
            throw new  ArgumentException("Product name must be defined");

        Order = order;
        Quantity = quantity;
        Product = product;
    }
}

আপনার সমস্ত পরামর্শের জন্য ধন্যবাদ।

উত্তর:


47

সেই বিষয়ে মার্টিন ফাউলারের একটি আকর্ষণীয় নিবন্ধ রয়েছে যা বেশিরভাগ লোক (আমাকে সহ) উপেক্ষা করার প্রবণতার একটি দিকটি হাইলাইট করে:

তবে একটি জিনিস যা আমি মনে করি যে প্রতিনিয়ত লোককে ট্রিপ দেয় তারা হ'ল যখন তারা প্রাসঙ্গিক স্বাধীন উপায়ে যেমন আইভালিড পদ্ধতিতে অবজেক্টের বৈধতা বলে মনে করে।

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

এর থেকে নিম্নলিখিতটি জানা যায় যে কন্সট্রাক্টরের বৈধতা যাচাই করা উচিত নয় , সম্ভবত কয়েকটি প্রাসঙ্গিক দ্বারা ভাগ করা কিছু প্রাথমিক বুদ্ধি পরীক্ষা checking

আবার নিবন্ধ থেকে:

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


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

2
@psr আপনার ডেটা অব্যাহত না থাকলে কি আপনার কি ব্যাক-এন্ড যুক্তি প্রয়োজন? আপনার ব্যবসায়ের মডেলটিতে যদি আপনার ডেটাটির কোনও অর্থ না থাকে তবে আপনি ক্লায়েন্টের পক্ষে সমস্ত হেরফের ছেড়ে দিতে পারেন। ডেটা অর্থহীন হলে বার্তা এবং বার্তা প্রেরণের জন্য সংস্থানসমূহের অপচয়ও হবে client সুতরাং আমরা "আপনাকে কখনই ডোমেন অবজেক্টগুলিকে অবৈধ অবস্থায় প্রবেশ করতে দেয় না!" এর আদর্শে ফিরে যাই! ।
জিও সি

2
আমি অবাক হয়েছি কেন এত দ্বিধাদ্বন্দ্বে উত্তরের জন্য এত বেশি ভোট? ডিডিডি ব্যবহার করার সময়, কিছু সময় এমন কিছু বিধি থাকে যা কিছু ডেটা INT হয় কিনা বা কোনও পরিসীমাতে থাকে তা কেবল খতিয়ে দেখেন। উদাহরণস্বরূপ, যখন আপনি আপনার অ্যাপ্লিকেশন ব্যবহারকারীকে তার পণ্যগুলির উপর কিছু বাধা বাছাই করতে দেন (কেউ আমার পণ্যটির কতবার পূর্বরূপ নিতে পারে এবং কোন মাসের ব্যবধানে)। এখানে উভয় সীমাবদ্ধতা int হওয়া উচিত এবং এর মধ্যে একটির মধ্যে 0-31 এর ব্যাপ্তি হওয়া উচিত। এটি ডেটা ফর্ম্যাট বৈধতা বলে মনে হয় যে কোনও ডিডিডি পরিবেশে কোনও পরিষেবা বা নিয়ামকের সাথে মানানসই। তবে ডিডিডিতে আমি ডোমেনে ভ্যালাইডিয়ন রাখার পক্ষে আছি (এর 90%)।
জিও সি

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

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

5

এই প্রশ্নটি একটু বাসি হওয়া সত্ত্বেও, আমি সার্থক কিছু যুক্ত করতে চাই:

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

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

আমি মনে করি প্রসঙ্গে নির্ভরযোগ্য বৈধতা এবং অবজেক্টগুলি তৈরি করা সহজভাবে ব্যবহার করা আপনার সিস্টেমকে রাস্তা দিয়ে কাজ করা আরও সহজ করে তুলবে।


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

4

আমি নিশ্চিত যে আপনি ইতিমধ্যে জানেন ...

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

ক্যাটার প্যারামিটার হিসাবে পাস করা ডেটার বৈধতা যাচাই করা নির্ধারকটিতে অবশ্যই কার্যকর valid অন্যথায় আপনি সম্ভবত একটি অবৈধ অবজেক্ট তৈরির অনুমতি দিচ্ছেন।

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


এছাড়াও, আপনার কোডের নমুনায় আপনি যেমন অন্তর্ভুক্ত করেছেন তেমন পার্শ্ব নোট ...

যতক্ষণ না আপনি আরও বৈধতা (অথবা অন্যান্য কার্যকারিতা) করছেন AddOrderLine, আমি সম্ভবত এক্সপোজ চাই List<LineItem>একটি সম্পত্তি হিসেবে বদলে আছে Orderএকটি হিসাবে কাজ ছদ্মরূপ


কেন পাত্রে ফাঁস? পাত্রটি কী তা উপরের স্তরগুলির সাথে কী আসে যায়? কোনও AddLineItemপদ্ধতি থাকা একেবারে যুক্তিযুক্ত । আসলে, ডিডিডি-র জন্য এটি পছন্দ করা হয় is যদি List<LineItem>কোনও কাস্টম সংগ্রহের অবজেক্টে পরিবর্তন করা হয়, তবে উন্মুক্ত সম্পত্তি এবং কোনও List<LineItem>সম্পত্তির উপর নির্ভরশীল সমস্ত কিছুই পরিবর্তন, ত্রুটি এবং ব্যতিক্রম সাপেক্ষে।
IAbstract

4

বৈধতা যত তাড়াতাড়ি সম্ভব সঞ্চালন করা উচিত।

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

আপনার প্রশ্নের ভিত্তিতে, আমি অনুমান করি উত্তরটি বৈধতা বিভক্ত করা হবে।

  1. সম্পত্তির বৈধতা যাচাই করে that সম্পত্তিটির মান সঠিক কিনা উদাহরণস্বরূপ যখন 1-10 এর মধ্যে ব্যাপ্তি শেষ হয়।

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

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

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

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

তাই এটি কয়েকটি বিখ্যাত শব্দ "এটি নির্ভর করে" দিয়ে বলতে, তবে কমপক্ষে আপনি এখনই জানেন যে এটি নির্ভর করে।

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

এই কারণে আমি বৈধতা ব্যতীত কেবলমাত্র একটি সম্পত্তি স্তর নিক্ষেপ করি। সমস্ত "ভাঙ্গা বিধি" সংগ্রহ করতে এবং একক সমষ্টিগত এক্সসেপশনে তাদের ব্যবহারকারীর কাছে প্রেরণ করার জন্য আমি ইস্ভালিড পদ্ধতিতে যাচাইকরণ ফলাফল ব্যবহার করি All

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

এটি আমাকে ব্যতিক্রম নিতে দেয় এবং প্রতিটি ইনপুট নিয়ন্ত্রণে স্বতন্ত্র ত্রুটিগুলি দেখানোর জন্য বা এটি চ্যাপ্ট করে একক তালিকায় দেখানোর জন্য এটি আলাদা করে দেয়। সিদ্ধান্ত আপনার.

এ কারণেই আমি এটিকে যথাসম্ভব শর্ট সার্কিটের জন্য উপস্থাপনা বৈধতার কথাও উল্লেখ করেছি।

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

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