দর্শন মডেলগুলিতে ব্যবসায়িক অবজেক্ট ব্যবহার করা


11

পুনরায় ব্যবহারযোগ্য ব্যবসায়িক অবজেক্টগুলি ব্যবহার করার সময়, ভিউ মডেলগুলি তৈরি করার সময় কোনটি অনুশীলন হিসাবে বিবেচনা করা হয়?

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

একজন বিল্ডার একটি ভিউ মডেল তৈরি করতে এক বা একাধিক স্ট্যান্ডার্ড ব্যবসায়িক সামগ্রীর মাধ্যমে ডেটা টানতে পারে।

যখন দেখা মডেলগুলিতে ব্যবসায়িক অবজেক্ট / মডেলগুলি ব্যবহার করার কথা হয় তখন কী আরও ভাল অনুশীলন হিসাবে বিবেচিত হয়?

পদ্ধতির ঘ

ভিউ মডেলটিতে ব্যবসায়িক জিনিসগুলির ব্যবহারের অনুমতি দেবেন?

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary();
        obModel.Order = obOrder;

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public Some.Business.Logic.Order Order;
    //Other methods for additional logic based on the order
    //and other properties
}

পদ্ধতির ঘ

ব্যবসায়ের জিনিসগুলি থেকে কেবল প্রয়োজনীয় ডেটা নিন

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary()
        {
            OrderNum = obOrder.OrderNum,
            NumOrderLnes = obOrder.NumOrderLines,
        }

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public int OrderNum;
    public int NumOrderLines
    //Other methods for additional logic based on the order
    //and other properties
}

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

উত্তর:


12

বিকল্প 1 ডোমেন মডেল এবং ভিউয়ের মধ্যে একটি দৃ tight় সংযোগ তৈরি করে। মডেলগুলি সমাধান করার জন্য ডিজাইন করা হয়েছে এটি খুব সমস্যার বিপরীতে।

একটি ভিউ মডেল "পরিবর্তনের কারণ" হয় যদি ভিউ নিজেই পরিবর্তন হয়। ভিউ মডেলটিতে একটি ডোমেন মডেল অবজেক্ট রেখে আপনি পরিবর্তন করার জন্য আরও একটি কারণ পেশ করছেন (যেমন ডোমেন পরিবর্তন হয়েছে)। এটি একক দায়িত্বের নীতি লঙ্ঘনের সুস্পষ্ট ইঙ্গিত। দুটি বা আরও বেশি কারণ থাকার কারণে মডেলগুলি দেখা যায় যার জন্য অনেক রক্ষণাবেক্ষণ প্রয়োজন - সম্ভবত ডোমেন / ভিউ মডেলের জুড়ে সদৃশ রক্ষণাবেক্ষণ ব্যয়ের চেয়ে বেশি।

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


আমি কি এই ভেবে সঠিক হয়েছি যে "পরিবর্তনের কারণ" দ্বারা আপনি বোঝাচ্ছেন কোনও রক্ষণাবেক্ষণ অর্থে পরিবর্তন, কোনও আপডেটিং (যেমন ইউআই ইভেন্ট) অর্থে পরিবর্তন হয় না?
অ্যান্ডি হান্ট

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

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

যদি আপনার কোনও ভিএম-তে ডোমেন অবজেক্ট না থাকতে পারে তবে আপনি কীভাবে অর্ডারগুলির অ্যারের মতো আরও জটিল কিছু উপস্থাপন করবেন?
জেফ

তাই মত, বলে মানে জিনিস আছে, ব্যবহারকারী প্রদর্শনের জন্য একটি টাইমস্ট্যাম্প বিন্যাস করুন, দেখুন স্তর, অন্তর্গত উচিত নয় ডোমেইন স্তর, এবং ডোমেইন স্তর বস্তু দৃশ্য বস্তু শুধুমাত্র একটি কাঁচা, অবিন্যস্ত টাইমস্ট্যাম্প ফেরত পাঠাবেন এবং পরেরটির কি উচিত বিন্যাস যুক্তি আছে?
The_Sympathizer

2

কোডের সদৃশতা এড়ানো হওয়ায় বিকল্প 1 পছন্দনীয়। এটাই.

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

একটি পৃথক দর্শন মডেল থাকার বিষয়টি হ'ল ব্যবসায়ের মডেল থেকে পৃথক পৃথক দৃষ্টিভঙ্গি (উদাহরণস্বরূপ কোন ট্যাবটি নির্বাচিত) এর জন্য অর্থবহ এমন রাষ্ট্রটি রাখা। তবে ব্যবসায়ের ডেটা নিজেই নকলের পরিবর্তে পুনরায় ব্যবহার করা উচিত।


ইয়াগনি - বেশিরভাগ সফ্টওয়্যার ডিজাইনের সমস্যাগুলি সমাধান করার গোপন ঘাতক।
মার্টিন ব্লোর

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

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

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

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

2

নীতি ও মন্ত্রগুলি কখনও কখনও গাইডিং ডিজাইনের জন্য মূল্যবান ... তবে এখানে আমার ব্যবহারিক উত্তরটি দেওয়া হয়:

আপনার ভিউ মডেলগুলি JSON বা XML- এ সিরিয়ালযুক্ত করা হয়েছে তা কল্পনা করুন। যদি আপনি নিজের ডোমেন মডেলগুলি চেষ্টা ও সিরিয়ালাইজ করেন তবে আপনি পাঠ্যের একটি জঘন্য জগাখিচুড়ি দিয়ে শেষ হতে চলেছেন এবং সম্ভবত বিজ্ঞপ্তিযুক্ত রেফারেন্স এবং অন্যান্য সমস্যাগুলি নিয়ে আসে।

দর্শন মডেলটির উদ্দেশ্য হ'ল ডোমেন মডেলগুলিকে একসাথে গোষ্ঠীভুক্ত করা নয় যাতে দৃশ্যটি সেগুলি গ্রাস করতে পারে। পরিবর্তে দর্শন মডেলটি হ'ল একটি সম্পূর্ণ সমতল মডেল হওয়া উচিত ... আপনি পর্দায় যা দেখছেন তা আসল জিনিস। আপনার দর্শন যুক্তিটি কেবলমাত্র ভিউ মডেলটিতে উপস্থিত ডেটা কাঠামোর সাথে সম্পর্কিত হতে হবে।

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


2
ডোমেন মডেলগুলিকে সিরিয়ালকরণে আমার কোনও সমস্যা হয়নি had এবং মডেলটিতে স্ট্রিংগুলিতে সবকিছু রূপান্তর করা হচ্ছে? সিরিয়াসলি?
মাইকেল বর্গওয়ার্ট

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

দুঃখিত, তবে এটি কোনও অ্যাপ্লিকেশন, পিরিয়ডের জন্য ভয়ঙ্কর পরামর্শ। এটি ডুপ্লিকেট কোড পূর্ণ পূর্ণ ওভাররেইঞ্জিনার্ড অ্যাপ্লিকেশনগুলিতে নিয়ে যায় যা নমনীয়ের ঠিক বিপরীত।
মাইকেল বর্গওয়ার্ট

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

@ ম্যাটডাভে: মনে হচ্ছে আপনি যে ডোমেন মডেলগুলির সাথে কাজ করতে অভ্যস্ত তা কেবল ধনী নয়, সত্যিকারের ক্লেপোক্র্যাটস। আমি রক্তাল্পের মডেলগুলি পছন্দ করি না তবে তারা এখনও মডেল এবং তাদের আচরণটি ডোমেনের প্রতিনিধিত্বের মধ্যে সীমাবদ্ধ থাকা উচিত। একক দায়িত্বের নীতি এবং
এগুলি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.