ক্লিন আর্কিটেকচার একটি ব্যবহারের ক্ষেত্রে উপস্থাপক (যা ইনজেকশনের হয় চোবান নিম্নলিখিত,) প্রকৃত বাস্তবায়ন কল ইন্টারঅ্যাক্টার প্রতিক্রিয়া / প্রদর্শন হ্যান্ডেল করতে দেওয়া দাড়ায়। যাইহোক, আমি এই আর্কিটেকচারটি বাস্তবায়নকারী ব্যক্তিদের, ইন্টারেক্টর থেকে আউটপুট ডেটা ফিরিয়ে আনতে এবং তারপরে নিয়ামককে (অ্যাডাপ্টারের স্তরে) কীভাবে এটি পরিচালনা করবেন তা সিদ্ধান্ত নিতে দিন। ইন্টারেক্টরের সাথে স্পষ্টভাবে ইনপুট এবং আউটপুট পোর্টগুলি সংজ্ঞায়িত না করা ছাড়াও দ্বিতীয় সমাধানটি কি অ্যাপ্লিকেশন স্তরটির বাইরে অ্যাপ্লিকেশন দায়িত্বগুলি ফাঁস হয়?
ইনপুট এবং আউটপুট পোর্ট
ক্লিন আর্কিটেকচার সংজ্ঞা এবং বিশেষত একটি নিয়ামক, একটি ব্যবহারের ক্ষেত্রে ইন্টারেক্টর এবং উপস্থাপকের মধ্যে সম্পর্কের বর্ণনা দেওয়ার জন্য সামান্য ফ্লো ডায়াগ্রাম বিবেচনা করে , "ইউজ কেস আউটপুট পোর্ট" কী হওয়া উচিত তা আমি সঠিকভাবে বুঝতে পেরেছি কিনা তা নিশ্চিত নই।
ষড়ভুজ আর্কিটেকচারের মতো পরিষ্কার আর্কিটেকচার প্রাথমিক পোর্ট (পদ্ধতি) এবং গৌণ পোর্টগুলির (অ্যাডাপ্টারের দ্বারা প্রয়োগ করা ইন্টারফেস) মধ্যে পার্থক্য করে। যোগাযোগের প্রবাহ অনুসরণ করার পরে, আমি প্রত্যাশা করি "ইউজ কেস ইনপুট পোর্ট" একটি প্রাথমিক বন্দর হবে (সুতরাং কেবল একটি পদ্ধতি), এবং "ইন্টারফেস কেস আউটপুট পোর্ট" প্রয়োগ করা হবে একটি ইন্টারফেস, সম্ভবত কোনও নির্মাণকারী যুক্তি আসল অ্যাডাপ্টার গ্রহণ করবে, যাতে ইন্টারেক্টর এটি ব্যবহার করতে পারে।
কোড উদাহরণ
একটি কোড উদাহরণ তৈরি করতে, এটি নিয়ামক কোড হতে পারে:
Presenter presenter = new Presenter();
Repository repository = new Repository();
UseCase useCase = new UseCase(presenter, repository);
useCase->doSomething();
উপস্থাপক ইন্টারফেস:
// Use Case Output Port
interface Presenter
{
public void present(Data data);
}
অবশেষে, ইন্টারেক্টর নিজেই:
class UseCase
{
private Repository repository;
private Presenter presenter;
public UseCase(Repository repository, Presenter presenter)
{
this.repository = repository;
this.presenter = presenter;
}
// Use Case Input Port
public void doSomething()
{
Data data = this.repository.getData();
this.presenter.present(data);
}
}
উপস্থাপককে কল করার কথোপকথনে
পূর্ববর্তী ব্যাখ্যাটি উপরোক্ত চিত্রটি নিজেই দ্বারা নিশ্চিত হওয়া গেছে বলে মনে হয় যেখানে নিয়ামক এবং ইনপুট পোর্টের মধ্যে সম্পর্কটি একটি "তীক্ষ্ণ" মাথাযুক্ত একটি শক্ত তীর দ্বারা প্রতিনিধিত্ব করে ("সংঘের" জন্য ইউএমএল, যার অর্থ "একটি" থাকে, যেখানে কন্ট্রোলারের একটি "ব্যবহারের কেস থাকে", যখন উপস্থাপক এবং আউটপুট পোর্টের মধ্যে সম্পর্ক একটি "সাদা" মাথা ("উত্তরাধিকারের জন্য ইউএমএল") দ্বারা দৃ a় তীর দ্বারা প্রতিনিধিত্ব করে, যা "বাস্তবায়ন" এর জন্য এক নয়, তবে সম্ভবত এটি যাইহোক অর্থ)।
তদ্ব্যতীত, অন্য একটি প্রশ্নের উত্তরে রবার্ট মার্টিন হুবহু ব্যবহারের ক্ষেত্রে বর্ণনা করেছেন যেখানে ইন্টারেক্টর একটি উপস্থাপককে পড়ার অনুরোধের পরে ডাকে:
মানচিত্রে ক্লিক করার ফলে স্থান পিনকন্ট্রোলারটিকে অনুরোধ করা হয়। এটি ক্লিকের অবস্থান এবং অন্য কোনও প্রাসঙ্গিক তথ্য সংগ্রহ করে, একটি প্লেসপিনেভেস্ট তথ্য কাঠামো তৈরি করে এবং পিনের অবস্থানটি যাচাই করে এটি প্লেসপাইন ইন্টারেক্টরকে প্রেরণ করে, প্রয়োজনে এটি বৈধ করে, পিনটি রেকর্ড করার জন্য একটি স্থান সত্তা তৈরি করে, একটি সম্পাদনাপ্লেস রিপোনস গঠন করে বস্তু এবং এটি এডিটপ্লেসপ্রেসেন্টারে পাস করে যা স্থান সম্পাদক স্ক্রিনটি উপস্থিত করে।
এমভিসি দিয়ে এই নাটকটি আরও ভালভাবে তৈরি করতে, আমি ভাবতে পারি যে traditionতিহ্যগতভাবে নিয়ামকের মধ্যে থাকা অ্যাপ্লিকেশন যুক্তিটি এখানে ইন্টারঅ্যাক্টরে স্থানান্তরিত হয়েছে, কারণ আমরা অ্যাপ্লিকেশন স্তরের বাইরে কোনও অ্যাপ্লিকেশন যুক্তি চাই না। অ্যাডাপ্টার স্তরের নিয়ামক কেবল ইন্টারঅ্যাক্টরকে কল করতে পারে এবং প্রক্রিয়াটিতে কিছু ছোট ডেটা ফর্ম্যাট রূপান্তর করতে পারে:
এই স্তরের সফ্টওয়্যারটি অ্যাডাপ্টারের একটি সেট যা ব্যবহারের ক্ষেত্রে এবং সত্তাগুলির জন্য সবচেয়ে সুবিধাজনক ফর্ম্যাট থেকে ডেটা রূপান্তর করে যা ডাটাবেস বা ওয়েবের মতো কিছু বাহ্যিক এজেন্সির জন্য সবচেয়ে সুবিধাজনক ফর্ম্যাটে রূপান্তর করে।
মূল নিবন্ধ থেকে, ইন্টারফেস অ্যাডাপ্টার সম্পর্কে কথা বলা।
মিথস্ক্রিয় তথ্য ফেরত
যাইহোক, এই পদ্ধতির সাথে আমার সমস্যাটি হ'ল ব্যবহারের ক্ষেত্রে অবশ্যই উপস্থাপনার যত্ন নেওয়া উচিত। এখন, আমি দেখতে পাচ্ছি যে Presenterইন্টারফেসের উদ্দেশ্যটি বিভিন্ন উপস্থাপক (জিইউআই, ওয়েব, সিএলআই, ইত্যাদি) উপস্থাপনের জন্য যথেষ্ট বিমূর্ত হতে পারে এবং এর সত্যিকার অর্থে "আউটপুট" বোঝায় যা ব্যবহারের ক্ষেত্রে কিছু হতে পারে খুব ভাল আছে, কিন্তু এখনও আমি এটির সাথে পুরোপুরি আত্মবিশ্বাসী নই।
এখন, ক্লিন আর্কিটেকচারের অ্যাপ্লিকেশনগুলির জন্য ওয়েবে ঘুরে দেখছি, আমি কেবলমাত্র কিছু ডিটিও ফিরিয়ে দেওয়ার পদ্ধতি হিসাবে আউটপুট পোর্টটির ব্যাখ্যার লোক খুঁজে পাচ্ছি। এটি এমন কিছু হবে:
Repository repository = new Repository();
UseCase useCase = new UseCase(repository);
Data data = useCase.getData();
Presenter presenter = new Presenter();
presenter.present(data);
// I'm omitting the changes to the classes, which are fairly obvious
এটি আকর্ষণীয় কারণ আমরা ব্যবহারের কেস থেকে উপস্থাপনাটিকে "কলিং" করার দায়িত্বটি সরিয়ে রেখেছি, সুতরাং ব্যবহারের ক্ষেত্রে কেবল তথ্য সরবরাহের পরিবর্তে ডেটা নিয়ে আর কী করা উচিত তা জেনে নিজেরাই উদ্বেগ প্রকাশ করে না। এছাড়াও, এই ক্ষেত্রে আমরা এখনও নির্ভরতা নিয়ম ভঙ্গ করছি না, কারণ ব্যবহারের ক্ষেত্রে এখনও বাইরের স্তর সম্পর্কে কিছুই জানে না।
তবে, প্রকৃত উপস্থাপনাটি আর সঞ্চালিত হওয়ার সময় ব্যবহারের ক্ষেত্রে সেই মুহুর্তটি নিয়ন্ত্রণ করা হয় না (যা কার্যকর হতে পারে, উদাহরণস্বরূপ সেই সময়ে অতিরিক্ত জিনিসগুলি যেমন লগিং করা বা প্রয়োজনে এটি পুরোপুরি বাতিল করা)। এছাড়াও, লক্ষ্য করুন যে আমরা ইউজ কেস ইনপুট পোর্টটি হারিয়েছি, কারণ এখন নিয়ামক কেবল সেই getData()পদ্ধতিটিই ব্যবহার করছেন (এটি আমাদের নতুন আউটপুট পোর্ট)। তদুপরি, এটি আমার কাছে মনে হচ্ছে যে আমরা এখানে "বলুন, জিজ্ঞাসা করবেন না" নীতিটি ভঙ্গ করছি, কারণ আমরা ইন্টারেক্টরকে প্রকৃত কাজটি করতে বলার চেয়ে কিছু তথ্য দিয়ে এর সাথে কিছু করার জন্য বলছি প্রথম স্থান.
যথাযথ
সুতরাং, এই দুটি বিকল্পের মধ্যে কোনও কি ক্লিন আর্কিটেকচার অনুসারে ইউজ কেস আউটপুট বন্দরের "সঠিক" ব্যাখ্যা? তারা উভয়ই কি কার্যকর?
