পরিষেবাগুলি কি সর্বদা ডিটিওগুলি ফিরিয়ে দেয়, না তারা ডোমেন মডেলগুলিও ফেরত দিতে পারে?


174

আমি (পুনরায়) বড় আকারের অ্যাপ্লিকেশন ডিজাইন করছি, আমরা ডিডিডি ভিত্তিক মাল্টি-লেয়ার আর্কিটেকচার ব্যবহার করি।

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

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

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

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

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

সর্বদা হিসাবে, আপনাকে ধন্যবাদ।


28
যারা ছেলেদের নিকট পক্ষে ভোট দেয় - দয়া করে আপনি কেন এই প্রশ্নটিকে মতামতের ভিত্তিতে বন্ধ করতে চান তা বোঝানোর যত্ন নেবেন?
রবার্ট গোল্ডওইন

20
@ অ্যারন "কোড পর্যালোচনা আপনি সমালোচনা করার জন্য যে প্রকল্পগুলিতে কাজ করছেন তার কোড ভাগ করার জন্য একটি প্রশ্ন ও উত্তর সাইট and" - আমার প্রশ্নটি কোড সম্পর্কে মোটেই নয়, সুতরাং এটি সেখানে বিষয়বস্তু থেকে মুক্ত হবে; SO: "আপনি যে সত্যিকারের সমস্যার মুখোমুখি হয়ে গেছেন সে সম্পর্কে প্রশ্নের উপর ফোকাস করুন you আপনি কী চেষ্টা করেছেন এবং ঠিক কী করার চেষ্টা করছেন সে সম্পর্কে বিশদ অন্তর্ভুক্ত করুন।" - আমার নির্দিষ্ট বিশেষজ্ঞের সমস্যা আছে, যা আমি সমাধান করার চেষ্টা করেছি। আপনি কি দয়া করে এই প্রশ্নের কী ভুল তা আরও সুনির্দিষ্ট করে বলতে পারেন, যেহেতু এখানে অনেকগুলি প্রশ্ন স্থাপত্য সম্পর্কিত এবং এই জাতীয় প্রশ্নগুলি আপাতদৃষ্টিতে ঠিক আছে, তাই আমি আরও কোনও ভুল বোঝাবুঝি এড়াতে পারি?
রবার্ট গোল্ডওইন

7
এই প্রশ্ন জিজ্ঞাসা করার জন্য আপনাকে ধন্যবাদ। আপনি আমার প্রতি অনুগ্রহ করেছেন, এবং আমার জীবনকে অনেক সহজ এবং সুখী করেছেন, ধন্যবাদ।
লোয়া

9
@ রবার্টগল্ডউইন, এসও ক্লোজ মাফিয়াকে আপত্তি করবেন না, আপনার প্রশ্নটি বৈধ।
hyankov

3
এই প্রশ্নটি জিজ্ঞাসা করার জন্য আপনাকে ধন্যবাদ
সালমান

উত্তর:


177

যখন ডোমেন মডেলটি ব্যবসায়ের স্তর ছেড়ে যায় (পরিষেবা স্তর) ঠিক মনে হয় না

আপনার কি মনে হচ্ছে আপনি ঠিক সাহস টানছেন? মার্টিন ফওলারের মতে: সার্ভিস লেয়ার অ্যাপ্লিকেশনটির সীমানা সংজ্ঞায়িত করে, এটি ডোমেনটিকে আবদ্ধ করে। অন্য কথায় এটি ডোমেনকে সুরক্ষা দেয়।

কখনও কখনও পরিষেবাটি এমন ডেটা অবজেক্ট ফিরিয়ে দেয় যা ডোমেনে সংজ্ঞায়িত হয়নি

আপনি কি এই ডেটা অবজেক্টের একটি উদাহরণ সরবরাহ করতে পারেন?

আমাদের যদি ডিটিওগুলিকে কঠোরভাবে আঁকড়ে রাখা উচিত তবে সেগুলি পরিষেবা স্তরে সংজ্ঞায়িত করা উচিত?

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

ডোমেন মডেলগুলি নিয়ন্ত্রণকারীদের কাছে সমস্ত উপায়ে ফিরে আসা কি ঠিক আছে, বা আমাদের সর্বদা পরিষেবা স্তরের সাথে যোগাযোগের জন্য ডিটিও ব্যবহার করা উচিত?

একটি ডিটিও হ'ল একটি প্রতিক্রিয়া / অনুরোধ বস্তু, আপনি যদি যোগাযোগের জন্য এটি ব্যবহার করেন তবে তা বোধগম্য হয়। আপনি যদি নিজের উপস্থাপনা স্তরে ডোমেইন মডেল ব্যবহার করেন (এমভিসি-কন্ট্রোলার / ভিউ, ওয়েবফর্মস, কনসোল অ্যাপ), তবে উপস্থাপনা স্তরটি আপনার ডোমেনের সাথে দৃly়ভাবে মিলিত হয়, ডোমেনের যে কোনও পরিবর্তনের জন্য আপনাকে আপনার নিয়ামকগুলি পরিবর্তন করতে হবে।

মনে হচ্ছে এটি ডিটিও তৈরি করতে খুব বেশি অর্থ বোধ করবে না যা ডোমেন মডেলের সমান)

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

ডিটিও আপনার আবেদনে অতিরিক্ত জটিলতা যুক্ত করতে পারে তবে আপনার স্তরগুলিও তাই। ডিটিও আপনার সিস্টেমের একটি ব্যয়বহুল বৈশিষ্ট্য, এগুলি বিনামূল্যে আসে না।

ডিটিও কেন ব্যবহার করবেন

এই নিবন্ধটি একটি ডিটিও ব্যবহার করার সুবিধা এবং অসুবিধা উভয়ই সরবরাহ করে, http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html

নিম্নরূপ সংক্ষিপ্তসার:

কখন ব্যবহার করতে হবে

  • বড় প্রকল্পের জন্য।
  • প্রকল্পের জীবনকাল 10 বছর বা তারও বেশি।
  • কৌশলগত, মিশন সমালোচনা প্রয়োগ।
  • বড় দল (5 এর বেশি)
  • বিকাশকারীগণ ভৌগলিকভাবে বিতরণ করা হয়।
  • ডোমেন এবং উপস্থাপনা আলাদা।
  • ওভারহেড ডেটা এক্সচেঞ্জগুলি হ্রাস করুন (ডিটিওর আসল উদ্দেশ্য)

কখন ব্যবহার করবেন না

  • ছোট থেকে মাঝের আকারের প্রকল্প (সর্বোচ্চ পাঁচ সদস্য)
  • প্রকল্পের জীবনকাল 2 বছর বা তার বেশি।
  • জিইউআই, ব্যাকএন্ড ইত্যাদির জন্য আলাদা কোনও দল নেই

ডিটিওর বিরুদ্ধে আর্গুমেন্টস

ডিটিও সহ যুক্তি

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

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

1
সেই গুরুত্বপূর্ণ ডোমেন মডেলগুলি বা ডিটিওগুলি কীভাবে আপনার পরিষেবা থেকে ফিরে আসে তা একটি গুরুত্বপূর্ণ পারফরম্যান্স বিবেচনা। EF- এর মাধ্যমে, যদি আপনি ডোমেন মডেলগুলির একটি কংক্রিট সংগ্রহ (যেমন .ToArray () বা ToList () সহ, উদাহরণস্বরূপ) ফেরত পাঠানোর কোনও কোয়েরি অনুধাবন করেন তবে আপনি উপলব্ধি হওয়া অবজেক্টগুলিকে জনপ্রিয় করতে সমস্ত কলামগুলি নির্বাচন করেন umns আপনি যদি এর পরিবর্তে ক্যোয়ারিতে ডিটিও প্রজেক্ট করেন তবে আপনার ডিটিওর জনসংখ্যার জন্য প্রয়োজনীয় কলামগুলি নির্বাচন করার জন্য EF স্মার্ট হয়, যা কিছু ক্ষেত্রে স্থানান্তর করার জন্য উল্লেখযোগ্যভাবে কম ডেটা হতে পারে।
হ্রেষাধ্বনি

10
আপনি নিজের হাতে 'অবধি' ম্যাপ করতে পারেন। আমি জানি, বিরক্তিকর স্টাফ, তবে মডেল প্রতি 2-3 মিনিট সময় লাগে এবং যখন আপনি প্রচুর প্রতিবিম্ব ব্যবহার করেন (অটোম্যাপার ইত্যাদি)
ডুমিত্রু

1
এত সহজ এবং এই জাতীয় সামগ্রীর সাথে উত্তর দেওয়ার জন্য ধন্যবাদ। আপনি আমার প্রতি অনুগ্রহ করেছেন, এবং আমার জীবনকে অনেক সহজ এবং সুখী করেছেন, ধন্যবাদ।
Loa

1
আমাদের একটি 10 ​​মিলিয়ন প্রকল্প বাতিল হয়ে গেছে কারণ এটি ধীর ছিল ... কেন এটি ধীর ছিল? রেফেকশন ব্যবহার করে সমস্ত জায়গায় ডিটিও অবজেক্ট স্থানান্তর করা। সতর্ক হোন. অটোম্যাপারগুলিও প্রতিবিম্ব ব্যবহার করে।
রায়লাভলেস

11

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

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

কোন পরিষেবার প্রয়োজনের ভিত্তিতে ডোমেন মডেলগুলি সামঞ্জস্য করা ঠিক আছে? একটি পরিষেবা কেবল সংগ্রহস্থল এবং ডোমেন পদ্ধতি এবং ডোমেন পরিষেবাগুলিতে কথা বলে, আপনার প্রয়োজনের ভিত্তিতে আপনার ডোমেনে ব্যবসায়টি সমাধান করা উচিত এবং ডোমেনটি কী প্রয়োজন তা জানানো কোনও পরিষেবার কাজ নয়।

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


1
এর জন্যে দুঃখিত! আপনি এটি দেখতে পারেন এখানে ehsanghanbari.com/blog/Post/7/…
এহসান

10

আমার অভিজ্ঞতায় আপনার ব্যবহারিক যা করা উচিত তা করা উচিত। "সেরা নকশাটি হ'ল সহজ নকশা যা কাজ করে" - আইনস্টাইন। মন দিয়ে ...

যদি আমরা দৃশ্যের মডেলগুলি কঠোরভাবে ব্যবহার করি, তবে নিয়ন্ত্রকদের কাছে সমস্তভাবেই ডোমেন মডেলগুলি ফিরিয়ে দেওয়া ঠিক হয়, বা আমাদের সর্বদা পরিষেবা স্তরের সাথে যোগাযোগের জন্য ডিটিও ব্যবহার করা উচিত?

একদম ঠিক আছে! আপনার যদি ডোমেন সত্তা, ডিটিও এবং ভিউ মডেলগুলি থাকে তবে ডাটাবেস টেবিল সহ আপনার কাছে সমস্ত জায়গায় 4 টি জায়গায় পুনরাবৃত্তি করা হয়েছে। আমি এমন বড় প্রকল্পগুলিতে কাজ করেছি যেখানে ডোমেন সত্তা এবং ভিউ মডেলগুলি ঠিক কাজ করেছে। এর একমাত্র এক্সপোজেশনটি হ'ল যদি অ্যাপ্লিকেশন বিতরণ করা হয় এবং পরিষেবা স্তরটি অন্য সার্ভারে থাকে যা ক্ষেত্রে ডিটিওগুলি সিরিয়ালকরণের কারণে তারের বাইরে পাঠাতে হয় to

যদি তা হয় তবে কিসের পরিষেবার প্রয়োজনের ভিত্তিতে ডোমেন মডেলগুলি ঠিক করতে ঠিক হবে? (সত্যি বলতে গেলে আমি তা মনে করি না, যেহেতু পরিষেবাগুলির ডোমেনের যা আছে তা গ্রাস করা উচিত))

সাধারণত আমি সম্মত হই এবং বলি না কারণ ডোমেন মডেলটি সাধারণত ব্যবসায়িক যুক্তির প্রতিচ্ছবি এবং সাধারণত সেই যুক্তির ভোক্তা আকৃতির হয় না।

আমাদের যদি ডিটিওগুলিকে কঠোরভাবে আঁকড়ে রাখা উচিত তবে সেগুলি পরিষেবা স্তরে সংজ্ঞায়িত করা উচিত? (আমি তাই মনে করি.)

আপনি যদি সেগুলি ব্যবহার করার সিদ্ধান্ত নেন তবে আমি সম্মত হয়েছি এবং হ্যাঁ বলেছি যে দিন শেষে ডিটিওগুলি ফিরিয়ে দেওয়ার কারণে পরিষেবা স্তরটিই সঠিক জায়গা।

শুভকামনা!


8

আমি এই পার্টিতে দেরি করছি, তবে এটি এমন একটি সাধারণ, এবং গুরুত্বপূর্ণ, প্রশ্ন যা আমি সাড়া দিতে বাধ্য হয়েছিল।

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

এই অধ্যায়ে, ইভান্স স্তরগুলি সম্পর্কে নিম্নলিখিত বলে:

একটি জটিল প্রোগ্রামকে স্তরগুলিতে বিভক্ত করুন। প্রতিটি স্তরের মধ্যে এমন একটি নকশা তৈরি করুন যা সংহত হয় এবং এটি কেবল নীচের স্তরগুলির উপর নির্ভর করে।

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

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

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

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

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

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

ক) ইন্টারফেস স্তর কেবলমাত্র এই ডোমেন অবজেক্টগুলিতে অ্যাক্সেস করতে সক্ষম হবে কেবল অ্যাপ্লিকেশন স্তরে কল দ্বারা প্রাপ্ত পঠনযোগ্য রিটার্ন মান হিসাবে

খ) অ্যাপ্লিকেশন লেয়ারের পরিষেবাগুলির পদ্ধতিগুলি কেবল "কাঁচা" ইনপুট (ডেটা মান) বা অবজেক্টের পরামিতিগুলি (যেখানে প্রয়োজন সেখানে প্যারামিটারের গণনা হ্রাস করার জন্য) হিসাবে গ্রহণ করে layer বিশেষত, অ্যাপ্লিকেশন পরিষেবাগুলি ডোমেন অবজেক্টগুলিকে ইনপুট হিসাবে কখনই গ্রহণ করে না

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


1
দ্রুত প্রশ্ন. আমি বর্তমানে আমার অ্যাপ্লিকেশন স্তর থেকে কী ফিরতে হবে তা নিয়ে ঘুরছি। অ্যাপ্লিকেশন স্তর থেকে ডোমেন সত্তা ফিরিয়ে দেওয়া ভুল অনুভব করে। আমি কি সত্যিই "বাইরের" ডোমেনটি ফাঁস করতে চাই? তাই আমি অ্যাপ্লিকেশন স্তরটি থেকে ডিটিওগুলি নিয়ে ভাবছিলাম। তবে এটি আরও একটি মডেল যুক্ত করে। আপনার প্রতিক্রিয়াতে আপনি বলেছিলেন যে আপনি ডোমেন মডেলগুলিকে "কেবলমাত্র পঠনযোগ্য রিটার্ন মান" হিসাবে ফিরিয়ে দেন। তুমি এটা কিভাবে করলে? অর্থাৎ আপনি কীভাবে কেবল সেগুলি পড়তে পারেন?
মাইকেল অ্যান্ড্রুজ

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

@ মিশেল অ্যান্ড্রুজ, আমার উত্তরটি সাহায্য করেছে শুনে খুশি। উত্তর: প্রত্যাবর্তিত বস্তুগুলি কেবলমাত্র পঠনযোগ্য হওয়া সম্পর্কে আপনার প্রশ্ন, বস্তুগুলি সেগুলি সত্যই পঠনযোগ্য নয় (অর্থাত্ অপরিবর্তনীয়)। আমার অর্থ হ'ল এটি অনুশীলনে ঘটে না (অন্তত আমার অভিজ্ঞতায়) experience কোনও ডোমেন অবজেক্ট আপডেট করার জন্য ইন্টারফেস লেয়ারটি হয় ক) ডোমেন অবজেক্টের রিপোজিটরিটি উল্লেখ করতে হবে, বা খ) অ্যাপলিকেশন লেয়ারে ফিরে এসে কলটিটি পেয়েছে এটি সবেমাত্র অবজেক্টটি আপডেট করেছে। এর মধ্যে দুটিই ভাল ডিডিডি অনুশীলনের এমন স্পষ্ট লঙ্ঘন যে আমি তাদের স্ব-প্রয়োগকারী বলে মনে করি। আপনি যত্ন নিলে উত্তর upvote নির্দ্বিধায়।
বিটমাস্ক 777

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

1
আমি আপনাকে কেবল একটি ফলো-আপ প্রশ্ন জিজ্ঞাসা করতে যাচ্ছিলাম এবং তারপরে আপনি ইতিমধ্যে এর জবাব দেখেছেন: "অ্যাপ্লিকেশন পরিষেবাগুলি ডোমেন অবজেক্টগুলিকে ইনপুট হিসাবে কখনই গ্রহণ করে না"। পারলে আমি আবার +1 করতাম।
রোবট্রন

5

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

প্রতিটি পরিষেবা পদ্ধতি তার নিজস্ব চুক্তিটি সংজ্ঞায়িত করে এবং তাই সময়ের সাথে সাথে বজায় রাখা সহজ। আমি আশা করি.


1
বছর পরে আমরা একই সিদ্ধান্তে এসেছি, ঠিক এখানে কারণগুলির জন্য reasons
রবার্ট গোল্ডউইন

@ রবার্টগোলডউইন এটি দুর্দান্ত! আমি এখন আমার সিদ্ধান্তে আরও আত্মবিশ্বাসী বোধ করি। :-)
নিক্লাস ওল্ফ

@ নিক্লাসওয়াল্ফ: সুতরাং, প্রশ্নে থাকা ডিটিস এখন অ্যাপ্লিকেশন লেয়ার চুক্তির অংশ, অর্থাত্ মূল / ডোমেনের অংশ। ওয়েব এপিআই রিটার্ন টাইপ সম্পর্কে কি ? আপনি কি আপনার উত্তরে উল্লিখিত ডিটিসগুলি প্রকাশ করেছেন বা ওয়েব এপিআই লেয়ারে আপনার ডেডিকেটেড ভিউ মডেলগুলি সংজ্ঞায়িত করা হয়েছে? বা অন্যভাবে বলতে গেলে: আপনি মডেলগুলি দেখার জন্য ডিটোসকে ম্যাপ করবেন?
রোবোট্রন

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

4

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

যেহেতু ডোমেন মডেল পুরো প্রয়োগের জন্য পরিভাষা ( সর্বব্যাপী ভাষা ) সরবরাহ করে তবে ডোমেন মডেলটি ব্যাপকভাবে ব্যবহার করা ভাল।

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

কখনও কখনও পরিষেবাটিকে ডেটা অবজেক্ট ফিরিয়ে আনা দরকার যা ডোমেনে সংজ্ঞায়িত হয়নি এবং তারপরে আমাদের হয় ম্যাপযুক্ত নয় এমন ডোমেনে নতুন অবজেক্ট যুক্ত করতে হবে, বা পোকো অবজেক্ট তৈরি করতে হবে (কিছুটা পরিষেবাদি ডোমেন মডেলগুলি ফেরত দেওয়ার পরে, কিছু) কার্যকরভাবে ডিটিওগুলি ফিরিয়ে দিন)।

আমি ধরে নিই যে আপনি অ্যাপ্লিকেশন / ব্যবসায় / ডোমেন লজিক পরিষেবাদি সম্পর্কে কথা বলছেন।

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

কখনও কখনও, 3 য় অংশের ফ্রেমওয়ার্কগুলি ব্যবহার করে এমন লোকেরা, যা ডোমেন সত্তার উপরে প্রক্সি তৈরি করে, তাদের পরিষেবাগুলি থেকে ডোমেন সত্তাগুলি প্রকাশে অসুবিধার সম্মুখীন হয় তবে এটি কেবল ভুল ব্যবহারের বিষয় of

প্রশ্নটি হ'ল - আমরা যদি দৃশ্যের সাথে মডেলগুলি কঠোরভাবে ব্যবহার করি তবে নিয়ন্ত্রণকারীদের কাছে সমস্তভাবেই ডোমেন মডেলগুলি ফেরা করা ঠিক আছে, বা আমাদের সর্বদা পরিষেবা স্তরের সাথে যোগাযোগের জন্য ডিটিও ব্যবহার করা উচিত?

আমি বলব 99,9% ক্ষেত্রে ডোমেন সত্তা ফিরিয়ে দেওয়া যথেষ্ট enough

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


4

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

একটি ডোমেন মডেলের একটি খুব গুরুত্বপূর্ণ দিকটি এটি পরিবর্তন করা সহজ। এটি আমাদের ডোমেনের পরিবর্তনের প্রয়োজনীয়তার সাথে নমনীয় করে তোলে।


2

আমি এই দুটি প্রশ্নের বিশ্লেষণের পরামর্শ দেব:

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

  2. আপনি গভীরভাবে আপনার উপরের স্তরগুলি পরিবর্তন করার সম্ভাবনা কতটা? (যেমন ডাব্লুপিএফ-এর জন্য এএসপি.এনইটি অদলবদল)। যদি এটি অত্যন্ত বিপরীত হয় এবং আপনার আর্কিটেকচার খুব জটিল না হয় তবে আপনি যতটা ডোমেন সত্তা পারছেন তেমন প্রকাশের চেয়ে ভাল।

আমি আশঙ্কা করছি যে এটি একটি বিস্তৃত বিষয় এবং এটি সত্যই আপনার সিস্টেম এবং এর প্রয়োজনীয়তার চেয়ে জটিল।


আমাদের ক্ষেত্রে, উপরের স্তর অবশ্যই পরিবর্তন হবে না। কিছু ক্ষেত্রে, পরিষেবাটি বেশ অনন্য POCO অবজেক্ট দেয় (আরও বেশি ডোমেন থেকে নির্মিত - যেমন, ব্যবহারকারী এবং তার নিজের ফাইল), কোনও ক্ষেত্রে কোনও পরিষেবা কেবল ডোমেন মডেল দেয় - যেমন, "FindUserByEmail () এর ফলাফলটি ব্যবহারকারীর ডোমেন মডেলটি ফিরে আসতে পারে - এবং এখানে আমার উদ্বেগের বিষয়, কখনও কখনও আমাদের পরিষেবা (গুলি) ডোমেন মডেলটি ফেরত দেয়, কখনও কখনও নতুন ডিটিও - এবং আমি এই অসঙ্গতি পছন্দ করি না, আমি যতটা নিবন্ধগুলি পড়তাম এবং সংখ্যাগরিষ্ঠ সম্মত বলে মনে হয় যদিও ম্যাপিং ডোমেন মডেল <-> ডিটিও হ'ল 1: 1, ডোমেন মডেলটি পরিষেবা স্তরটি ছেড়ে দেওয়া উচিত নয় - তাই আমি ছেঁড়া।
রবার্ট গোল্ডওইন

এই জাতীয় পরিস্থিতিতে এবং সরবরাহ করা হয়েছে যে আপনি অতিরিক্ত বিকাশের প্রচেষ্টা সহ্য করতে পারেন আমি ম্যাপিংয়ের সাথেও যাব যাতে আপনার লেয়ারিং আরও সামঞ্জস্যপূর্ণ হয়।
jnovo

1

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

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