এমভিসি কি কেবল পিএইচপি প্রোগ্রামিংয়ের এসইও?


9

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

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

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

কিছু বিশদ যুক্তি

আমার কেন সন্দেহ হয় যে পিএইচপি বাস্তবায়নগুলি বাস্তব এমভিসি প্যাটার্ন অনুসরণ করে না:

মডেলগুলি : তত্ত্ব অনুসারে, মডেলগুলি চর্বিযুক্ত হওয়া উচিত এবং এতে ব্যবসায়িক যুক্তি থাকতে হবে এবং নিয়ামকগুলি পাতলা হ্যান্ডলারের (ইনপুট-> আউটপুট) হওয়া উচিত। বাস্তবে পিএইচপি ফ্রেমওয়ার্কগুলি অগভীর মডেলগুলির পক্ষে । সিআই এবং সিমফনি উদাহরণস্বরূপ মডেল == ওআরএম। এমনকি HTTP ইনপুটটি নিয়ামক দ্বারা পরিচালিত হয়, মডেল হিসাবে বিবেচিত হয় না।

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

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

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


সুতরাং, উপসংহারে: পিএইচপি ফ্রেমওয়ার্কগুলি মূল এমভিসির অনুরূপ একটি ধারণা বাস্তবায়ন করে। আমার মনে হয় এটি সর্বোত্তমভাবে এখানে পেরেক দেওয়া হয়েছে: stackoverflow.com/questions/1549857/simple-php-mvc-framework/…
মারিও

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

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

3
... এসইও? "সন্ধান যন্ত্র নিখুতকরন"?
ইজকাটা

উত্তর:


12

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

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

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

সুতরাং "মডেল-ভিউ-কন্ট্রোলার" নামটি পুরোপুরি যৌক্তিক, যদিও জিইউআই অ্যাপ্লিকেশন বনাম ওয়েব অ্যাপ্লিকেশনগুলিতে আলাদা প্রয়োগ রয়েছে।


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

3

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

মডেল:

তত্ত্ব অনুসারে, মডেলগুলি চর্বিযুক্ত এবং ব্যবসায়িক যুক্তিযুক্ত হওয়া উচিত

এটি সম্পূর্ণরূপে করতে হবে, পিএইচপি এর সাথে কী করার আছে তা আমি দেখতে পাচ্ছি না ...

মডেলগুলি পিএইচপি-তে ডেটা ক্লাস যা সম্ভবত ডাটাবেসের সাথে যোগাযোগ
করতে পারে , তবে আপনি একই মডেল বা JSON ফর্ম্যাটে একটি আংশিক মডেল ক্লায়েন্টকে প্রেরণ করতে পারেন।

আমি ব্যবসায়ের যুক্তি বলব না, এটি ডেটা যুক্তির মতো (বৈধতা, ডাটাবেস ইন্টারঅ্যাকশন, আমদানি / রফতানি, ...) like

এবং কন্ট্রোলারগুলি পাতলা হ্যান্ডলার হওয়া উচিত (ইনপুট-> আউটপুট)

আপনার কন্ট্রোলার ক্লাসগুলি মডেল ক্লাসগুলির সাথে যোগাযোগ করে, তারা সত্যই পাতলা।

আউটপুটের ভিত্তিতে, মডেলগুলি দিয়ে কিছু করুন ... এবং ক্লায়েন্টকে একটি মডেলভিউ ফিরিয়ে দিন ...

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

আমি এই পিএইচপি ফ্রেমওয়ার্কগুলি সম্পর্কে সত্যই সচেতন নই ...

তবে এইচটিটিপি ইনপুটটি নিয়ামকের কাছে পৌঁছানোর আগে হ্যান্ডল করা উচিত,
আপনি সহজেই একটি বর্গ তৈরি করতে পারেন যা জিইটি এবং পোষ্টের ডেটাগুলিকে ভাল রাউটিং এবং পরামিতিগুলিতে পরিণত করে।

এটিএসপি নেট নেট এমভিসি ২ তে ঠিক এটি ঘটে এবং এতে কোনও ভুল নেই,
পিএইচপি দিয়ে এটি কীভাবে ঘটবে তা আমি জানি না তবে আমি অনুমান করি এটির সাথে সম্পর্কিত হবে related

এমনকি আপনি সহজেই জিইটি এবং পোস্টের ডেটাটিকে একটি মডেলে রূপান্তর করতে পারেন, মডেলটিতে তার জন্য কনস্ট্রাক্টর যুক্তি থাকতে পারে। বা সেই উদ্দেশ্যে কিছু পৃথক শ্রেণি যুক্ত করা যেতে পারে।


দেখা হয়েছে:

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

আমি দেখতে পাচ্ছি না কেন এটি করতে পারছে না, পার্থক্য হ'ল একমাত্র পার্থক্য হ'ল পিএইচপি জেএসএন ইত্যাদি ফিরিয়ে দিতে পারে ...

একটি পৃষ্ঠা আপনার দৃষ্টিভঙ্গি এবং এটি AJAX + JSON এর মাধ্যমে অনুরোধ এবং আপডেট করতে পারে।
আবার, আমি এই পিএইচপি ফ্রেমওয়ার্কগুলি সম্পর্কে সত্যই সচেতন নই তবে এএসপি.নেট এমভিসি 2 তে এটি সেভাবে কাজ করে।

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

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


নিয়ন্ত্রক:

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

এমভিসি হ'ল একটি সফ্টওয়্যার আর্কিটেকচার / প্যাটার্ন, যেখানে কন্ট্রোলার চলে এবং কতক্ষণ ম্যাথার করে না।


1

কিন্তু পিএইচপি ওয়েব অ্যাপ্লিকেশনগুলি লাইভ ভিউ (জিইউআই উপাদানগুলি) এবং একটি নিয়মিত নিয়ামক রানটাইমটিতে পরিচালনা করে না।

না, তারা নিশ্চয়ই করে!

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

আপনি কুকি / সেশন ব্যবহার করতে পারবেন বলেও নিয়ামক অবিচল।

"এমভিসি" পিএইচপি ফ্রেমওয়ার্কগুলির জন্য একটি বাজওয়ার্ডের মতো ব্যবহৃত হয়েছে বলে মনে হচ্ছে।

এমভিসি একটি সফ্টওয়্যার আর্কিটেকচার, কিছু ফ্রেমওয়ার্ক এটিকে গুঞ্জন হিসাবে ব্যবহার করতে পারে তবে অন্যরা এটি সঠিকভাবে করেন ... উইকিপিডিয়ায় কিছু ফ্রেমওয়ার্কের একটি তালিকা
দেখুন ।

এমভিসি কি কেবল পিএইচপি প্রোগ্রামিংয়ের এসইও?

এমভিসি এবং এসইও দুটি জিনিস আলাদা, তবে হ্যাঁ ... এমভিসি আরও জনপ্রিয় হচ্ছে।


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

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

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

-1

আমার মতে পিএইচপি তে এমভিসি ব্যবহার করা প্রোগ্রামারে ওয়েবে নিয়ে আসে। আপনি যখন এমভিসির সাথে কীভাবে কাজ করবেন তা জানেন যখন জাভা থেকে পিএইচপি করা সহজতর হয়।


+1 তবে এটি কি কেবল একটি পরিভাষা সুবিধা, বা এমন কোনও পিএইচপি ফ্রেমওয়ার্ক রয়েছে যা জাভা বাস্তবায়নের নিকটে রয়েছে। (এবং স্পষ্টতই, আপনি জাভা জিইউআই বা ওয়েব / স্ট্রুটস সম্পর্কে কথা বলছেন?)
মারিও

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