চাচা ববের পরিষ্কার স্থাপত্য - প্রতিটি স্তরের জন্য কোনও সত্তা / মডেল শ্রেণি?


44

পিছনে:

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

আমি কী লক্ষ করেছি:

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

প্রশ্ন:

যখন প্রতিটি সিআরইউডি অপারেশন প্রয়োজন হয় তবে আমি জানি যে সমস্ত স্তরে মডেল ক্লাসগুলি থাকা দরকার? বা, পরিষ্কার আর্কিটেকচার ব্যবহার করার সময় এটি কোনও নিয়ম বা সেরা অনুশীলন?

উত্তর:


52

আমার মতে, এটি ঠিক কীভাবে বোঝানো হচ্ছে তা নয়। এবং এটি ডিআরওয়াই লঙ্ঘন।

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

যদি বাইরের আপনার ডাটাবেসগুলি objects অবজেক্টগুলি সরাসরি সঞ্চয় করতে পারে তবে স্তরগুলি পৃথক করার স্বার্থে এগুলি অন্য ফর্ম্যাটে ম্যাপিং করা কেবল অর্থহীন নয়, মডেলের নকল তৈরি করা এবং এটি উদ্দেশ্য নয়।

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

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

বিপরীতে, আপনি যদি নিজের ডোমেন পরিবর্তন করেন এবং আপনি এই সমস্ত ম্যাপার তৈরি করেন তবে আপনাকে অনেক কিছু পরিবর্তন করতে হবে।


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

যথা নীচে এখানে https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

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

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

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

এবং এখানে https://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html যা উপরে ঠিকানাগুলি:

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

এই আইএমওটি বোঝায় যে প্লেইন 1: 1 টির অনুলিপিটি আর্কিটেকচারে গন্ধ কারণ আপনি প্রকৃতপক্ষে সঠিক স্তর এবং / বা বিমূর্ততা ব্যবহার করছেন না।

পরে তিনি ব্যাখ্যা করেছেন যে কীভাবে তিনি সমস্ত "অনুলিপি" কল্পনা করছেন

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

এই অ্যাপ্লিকেশনটিতে উপস্থাপনার মধ্যে একটি বড় পার্থক্য রয়েছে। প্রবাহিত ডেটা কেবল সত্তা নয়। এবং এই ওয়ারেন্ট এবং বিভিন্ন শ্রেণীর দাবি।

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

সেখানে মধ্যে একটি পার্থক্য আছে "দুই মধ্যে সহজ ডাটা স্ট্রাকচার ক্ষণস্থায়ী মাধ্যমে ব্যবসার নিয়ম থেকে UI 'তে আলাদা" এবং "আপনি একটি ছবির পুনঃনামকরণ এটা 3 পথে বার প্রদর্শন করাতে চান যখন"

তদ্ব্যতীত, আমি যেখানে এই ডেমো অ্যাপ্লিকেশনগুলি পরিষ্কার আর্কিটেকচারের প্রতিনিধিত্ব করতে ব্যর্থ দেখতে পাচ্ছি তা হ'ল স্তরগুলি পৃথক করার স্বার্থে স্তরগুলি পৃথক করার উপর তারা প্রচুর জোর দেয় তবে অ্যাপ্লিকেশনটি কী কার্যকরভাবে আড়াল করে। এটি https://blog.8thlight.com/uncle-bob/2011/09/30/Screaming- আর্কিটেকচার html - এ যা বলা হয়েছে তার বিপরীতে name

কোনও সফ্টওয়্যার অ্যাপ্লিকেশনটির আর্কিটেকচার অ্যাপ্লিকেশনটির ব্যবহারের ক্ষেত্রে চিৎকার করে

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

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


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

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

1
@ রমিজেমলি ফ্রেমওয়ার্কগুলি ব্যবহার করা ভাল যা জীবনকে সহজ করে তোলে, মূল বিষয়টি হ'ল আপনার আর্কিটেকচার যখন তাদের উপর নির্ভর করে এবং আপনি সেগুলি সবকিছুর কেন্দ্রে রেখে শুরু করেন তখন আপনার যত্নবান হওয়া উচিত। এমনকি এখানে আরএক্সজাভা ব্লগ ৮.থলাইট. com / uncle- bob / 2015 / 08/ 06 / let- the - magic- die.html সম্পর্কে একটি নিবন্ধ রয়েছে - এটি আপনাকে বলছে না যে এটি ব্যবহার করা উচিত নয়। এটি আরও ভালো: আমি এটি দেখেছি, এটি এক বছরে অন্যরকম হতে চলেছে এবং আপনার অ্যাপ্লিকেশনটি এখনও আপনার চারপাশে থাকলে আপনি এটি আটকে আছেন। সরল পুরাতন সলাইড নীতি প্রয়োগ করার সময় এটিকে বিশদ করুন এবং সাদামাটা পুরাতন জাভাতে সর্বাধিক গুরুত্বপূর্ণ কাজগুলি করুন।
zapl

1
@ জ্যাপল আপনি কি ওয়েব সার্ভিস স্তর সম্পর্কে একইভাবে অনুভব করছেন? অন্য কথায়, আপনি কি @SerializedNameগসন টিকাগুলি কোনও ডোমেন মডেলটিতে রাখবেন? অথবা আপনি ডোমেন মডেলটিতে ওয়েব প্রতিক্রিয়া ম্যাপিংয়ের জন্য দায়ী একটি নতুন অবজেক্ট তৈরি করবেন?
tir38

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

7

আপনি আসলে এটি ঠিক আছে। এবং ডিআরওয়াইর কোনও লঙ্ঘন নেই কারণ আপনি এসআরপি গ্রহণ করেন।

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

ইউজকেস অ্যাপ্লিকেশন-নির্দিষ্ট যুক্তির জন্য দায়ী, ব্যবসায়িক বিষয়টি অ্যাপ্লিকেশন-স্বতন্ত্র যুক্তির জন্য এবং ডিএও সংরক্ষণের জন্য দায়বদ্ধ।

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

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

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


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

আমি রামির সাথে সম্মতি জানালাম, ম্যাপারটি অপ্রয়োজনীয় কারণ আপনি সরাসরি ইন্টারেক্টর প্রয়োগের ক্ষেত্রে ম্যাপিংটি করতে পারেন।
ক্রিস্টোফার পেরি

5

না, আপনার প্রতিটি স্তরে মডেল ক্লাস তৈরি করার দরকার নেই।

সত্তা ( DATA_LAYER) - ডাটাবেস অবজেক্টের সম্পূর্ণ বা আংশিক উপস্থাপনা।DATA_LAYER

ম্যাপার ( DOMAIN_LAYER) - প্রকৃতপক্ষে এমন একটি শ্রেণি যা সত্তাকে মডেলক্লাসে রূপান্তর করে, যা ব্যবহৃত হবেDOMAIN_LAYER

একবার দেখুন: https://github.com/lifedemons/photoviewer


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

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