নির্ভরতা ইনজেকশন: আমি একটি কাঠামো ব্যবহার করা উচিত?


24

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

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

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

আমি যেমন বলেছি, সাধারণত এটি ভাল কাজ করে।

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

ডিআই ফ্রেমওয়ার্কের সাথে কীভাবে কাজ করা আলাদা হবে এবং ম্যানুয়াল 'ভ্যানিলা' নির্ভরতা ইনজেকশনটির চেয়ে ভাল বা খারাপ কী তা শিখিয়ে নিন দয়া করে তা ব্যাখ্যা করুন।

সম্পাদনা: আমি এই প্রশ্নটি যুক্ত করতে চাই: আপনি কোনও 'পেশাদার স্তর' প্রকল্প দেখেছেন যা কোনও কাঠামো ছাড়াই ম্যানুয়ালি ডিআই করে?


আমার উত্তর পাশে। দুটি উপায়ই সামঞ্জস্যপূর্ণ। আপনি কাঠামোতে নরম নির্ভরতা ইনজেকশনটি ছেড়ে দিতে পারেন এবং গুরুত্বপূর্ণ কারখানার জন্য আপনার কারখানাগুলি রাখতে পারেন। মডেল বা ব্যবসায়ের সাথে সম্পর্কিত উপাদান।
লাইভ

4
আমার ধারণা আপনি ইতিমধ্যে চেক করেছেন, কেবলমাত্র আপনি যদি না হন তবে ডিআই এর জন্য আমাদের ফ্রেমওয়ার্কগুলি কেন প্রয়োজন?
লাইভ

উত্তর:


19

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

পটভূমিগুলি

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

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

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

নিচে দিকে ...

কনফিগারেশন সম্পর্কিত কনভেনশন বিমূর্তনটিকে এত ভারী করে তোলে যে আপনি কীভাবে এটি কাজ করে তা সবেমাত্র জানেন। কখনও কখনও যাদু মনে হয় এবং এখানে আরও একটি ত্রুটি আসে। একবার কাজ করার পরে, অনেক বিকাশকারী কীভাবে এটি কাজ করে তা নিয়ে চিন্তা করে না।

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

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

্যত্নদ্দন্ত...

একটি শব্দ উত্পাদনশীলতা । ফ্রেমওয়ার্কগুলি আমাদের সত্যিকারের বিষয়গুলিতে ফোকাস করতে দেয়। অ্যাপ্লিকেশন এর ব্যবসা।

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

পরীক্ষামূলক

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

ঠিক প্রলোভন লাগছে? সাবধান হও! ফাঁদে পড়বেন না !!

পরামর্শ

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

এই অনুশীলন সম্পর্কে:

ডিআই পাত্রে কখন ব্যবহার করবেন

আমার উত্তরটি নিজের অভিজ্ঞতার দ্বারা পক্ষপাতদুষ্ট হতে চলেছে যা মূলত ডিআই কনটেইনারগুলির পক্ষে হয় (যেমন আমি মন্তব্য করেছি যে আমি উত্পাদনশীলতার দিকে খুব বেশি মনোনিবেশ করছি, তাই আমার কখনই খাঁটি ডিআইয়ের প্রয়োজন হয় নি Qu বিপরীতে)।

আমি মনে করি আপনি এই বিষয় সম্পর্কে আকর্ষণীয় মার্ক সিমনের নিবন্ধটি পাবেন , যা খাঁটি ডিআই বাস্তবায়ন করতে হবে এমন প্রশ্নেরও উত্তর দেয় ।

শেষ পর্যন্ত, যদি আমরা জাভা বলছিলাম, আমি প্রথমে জেএসআর 330 - নির্ভরতা ইনজেকশনটির দিকে একবার বিবেচনা করব

সংক্ষেপিত

উপকারিতা :

  • ব্যয় কাটা এবং সময় সাশ্রয়। প্রমোদ.
  • উপাদানগুলির একটি ছোট সংখ্যা।
  • কোডটি সহজ এবং ক্লিনার হয়ে যায়।

ত্রুটিগুলি :

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

খাঁটি ডিআই এর সাথে পার্থক্য :

  • কম কোড এবং আরও কনফিগারেশন ফাইল বা টিকা।

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

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

যদি আপনি যা
বোঝেন

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

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

10

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

অ-বৈশ্বিক বস্তু

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

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

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

লাইব্রেরি

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

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

লুকানো জটিলতা

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

আইডিই সমর্থন

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

উপসংহার

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


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

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

এটি দুর্ভাগ্যজনক @ উইংস্টনওয়েয়ার্ট। আমার জন্য প্রসঙ্গে পূরণ করার জন্য ধন্যবাদ।
রাবারডাক

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

ইন্টেলিজ সিডিআই বুঝতে পারে (জাভা ইই স্ট্যান্ডার্ড ডিআই)
থরবজর্ন রাভন অ্যান্ডারসেন

3

জাভা + নির্ভরতা ইনজেকশন = ফ্রেমওয়ার্ক প্রয়োজন?

না।

একটি ডিআই ফ্রেমওয়ার্ক আমাকে কী কিনে?

জাভা নয় এমন ভাষায় অবজেক্ট কনস্ট্রাকশন হচ্ছে।


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

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

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

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

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

: যদি পরীক্ষামূলক সত্যিই এই দয়া বর্ণন পিছনে চালিকা শক্তি jUnit (যে কোন xUnit সত্যিই) এবং Mockito (যে কোন উপহাস সত্যিই) আপনি একটি দ্বি ফ্রেমওয়ার্ক চিন্তা আপনার জীবন ধরে নিতে হবে শুরু।

আপনি যা পছন্দ করেন তা করতে পারেন তবে গুরুতর কাজের জন্য আমি একটি সুইস সেনা ছুরির চেয়ে ভাল জনবহুল সরঞ্জাম বাক্সটিকে পছন্দ করি। আশা করি এই লাইনগুলি আঁকানো সহজ ছিল তবে কিছু তাদের এটিকে ঝাপসা করার জন্য কঠোর পরিশ্রম করেছে। এটির সাথে কোনও ভুল নয় তবে এটি এই পছন্দগুলি চ্যালেঞ্জিং করে তুলতে পারে।


পাওয়ারমক এর মধ্যে কয়েকটি মামলা সমাধান করেছে। অন্তত এটি আপনাকে স্ট্যাটিকস উপহাস করতে দেয়
লাইভ

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

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

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

2
@ রবারডাক বেশিরভাগ "কমপোজিশন শিকড়গুলি" আমি দেখেছি মূলত কোডের প্রায় 5 টি লাইন। সুতরাং না। অত্যধিক কঠিন কাজ নয়। এটি মালিকানাধীন জিনিস যা আমি যে লাইনে সাবধান করে দিচ্ছি সেগুলি ছাড়িয়ে যায়। আপনি এটিকে "ডিআই সঠিকভাবে করছেন" বলছেন। আপনি যদি একটি কোড পর্যালোচনায় সমস্যা প্রমাণ করতে ব্যবহার করেন তবে আপনি জিজ্ঞাসা করছি। নাকি আপনি শুধু "মেহ" বলবেন?
candied_orange

2

ক্লাস তৈরি করা এবং তাদের নির্ভরতা নির্ধারণ করা মডেলিংয়ের প্রক্রিয়া, মজার অংশ। বেশিরভাগ প্রোগ্রামার প্রোগ্রামিং উপভোগ করার কারণেই এটি।

কোনটি বাস্তবায়ন ব্যবহৃত হবে এবং শ্রেণিগুলি কীভাবে নির্মিত হবে তা সিদ্ধান্ত নেওয়া, এটি কোনওভাবে বাস্তবায়ন করতে হবে এবং এটি অ্যাপ্লিকেশন কনফিগারেশনের অংশ।

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

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

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

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

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

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

শেষ পর্যন্ত এটি সম্ভবত আপনার পছন্দগুলি কী এবং আপনি যে ত্যাগ করতে ইচ্ছুক তার (যা সময় লেখার সময় কারখানা বা স্বচ্ছতার জন্য) নেমে আসে most


ব্যক্তিগত অভিজ্ঞতা (সতর্কতা: বিষয়গত)

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

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


2

ব্যক্তিগতভাবে আমি ডিআই-পাত্রে ব্যবহার করি না এবং সেগুলি পছন্দ করি না। এর জন্য আমার আরও কয়েকটি কারণ রয়েছে।

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

এটি ওওপি নীতিগুলি যেমন: সংহতকরণ এবং ডেভিড ওয়েস্টের লেগো-ইট অবজেক্ট রূপককে ভঙ্গ করে

সুতরাং প্রোগ্রামের এন্ট্রি পয়েন্টের যতটা সম্ভব পুরো অবজেক্টটি তৈরি করা উপায়।


1

আপনি ইতিমধ্যে লক্ষ্য করেছেন: আপনি যে ভাষাটি ব্যবহার করেন তার উপর নির্ভর করে বিভিন্ন দৃষ্টিভঙ্গি রয়েছে, একইরকম সমস্যাগুলি কীভাবে মোকাবেলা করতে হবে তা আলাদা করে নেওয়া হয়।

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

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

এটি বলেছিল, ডিআই-কাঠামোর দরকার নেই।

তবে তবুও আপনি কেন একটি কাঠামো ব্যবহার করতে চান?

আমি) বয়লারপ্লেট কোড এড়িয়ে চলুন

যদি আপনার প্রকল্পটি একটি আকার পায়, যেখানে আপনি বারবার লেখার কারখানার (এবং ইনস্টিটিশনগুলি) ব্যথা অনুভব করেন, আপনার একটি ডিআই-ফ্রেমওয়ার্ক ব্যবহার করা উচিত

দ্বিতীয়) প্রোগ্রামিংয়ের জন্য ঘোষণামূলক পদ্ধতি

জাভা যখন এক্সএমএল দিয়ে প্রোগ্রামিং করছিল তখন এটি এখন: টীকাগুলির সাথে রূপকর্ম ছিটিয়ে দেওয়া এবং যাদুটি ঘটে

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


TL; ড

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


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

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

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

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

1
উত্তরটা এতই বদলে গেল !!! এমন কিছু যা আপনাকে চিন্তিত করে না :-)। বার্তা এবং তর্কগুলি একই থাকে। আমি কেবল আপনার উত্তরটি যেমন ছিল তেমন চালিয়ে যেতে চেয়েছিলাম। আমি অনুমান করি যে এটি কেবল আপনাকে উদ্ধৃতিগুলির একটি মুছে ফেলতে নিয়ে গেছে।
লাইভ

0

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


0

হ্যাঁ, জাভাতে কাজ করার সময়, আমি একটি ডিআই কাঠামোর প্রস্তাব দেব। এই জন্য কয়েক কারণ আছে:

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

  • জাভা টীকাগুলি অত্যন্ত কার্যকর এবং নির্ভরতাগুলি কনফিগার করার একটি দুর্দান্ত উপায় সরবরাহ করে

  • অজগরটিতে আপনি যা ব্যবহার করেছেন তার তুলনায় জাভা অবজেক্ট নির্মাণ অত্যধিক ভার্জোজ; এখানে একটি ফ্রেমওয়ার্ক ব্যবহার করা গতিশীল ভাষায় তার চেয়ে বেশি কাজ বাঁচায়।

  • জাভা ডিআই ফ্রেমওয়ার্কগুলি কার্যকর গতিযুক্ত ভাষার চেয়ে জাভাতে আরও বেশি কাজ করে এমন প্রক্সি এবং ডেকোরেটর উত্পন্ন করার মতো দরকারী জিনিসগুলি করতে পারে।


0

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

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

এই জাতীয় কোড সহ আপনি উপকারের চেয়ে বেশি ক্ষতি করতে পারেন।

আপনার যদি আরও অভিজ্ঞতা থাকে তবে আপনি সম্ভবত একটি ইন্টারফেস (কারখানা বা সার্ভিসিলোকেটর) দ্বারা ডি-ফ্রেমওয়ার্কটি বিমূর্ত করতে পারেন যাতে এই সমস্যাটির আর অস্তিত্ব থাকবে না এবং ডি ফ্রেমওয়ার্কটি সেই ক্ষতিটিকে আরও উপকৃত করবে।

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