মডিউল / প্লাগইন সমর্থন করার সময় আপনি কীভাবে আপনার এমভিসি কাঠামোটি সংগঠিত করেন? [বন্ধ]


17

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

স্ট্যান্ডার্ড এমভিসি

/controller
/model
/view

সমস্যা: সম্পর্কিত উপাদানগুলির কোনও পৃথকীকরণ নেই (ফোরাম, ব্লগ, ব্যবহারকারী, ইত্যাদি))

মডুলার এমভিসি

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

মডিউল-ভিত্তিক সিস্টেমটি বাছাই করা আপনাকে একটি সমস্যা থেকে দূরে রাখবে।

  • দীর্ঘ নাম (ফোরাম_মোডেল_ফোরাম = ফোরাম / মডেল / ফোরাম.এফপি) (জেন্ডের মতো)
  • is_file()ফোরামের মডেলটি কোন ফোল্ডারে রয়েছে তা অনুসন্ধান করতে ফাইল সিস্টেম অনুসন্ধান করে ? (কোহানার মতো)

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


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

উত্তর:


9

চেষ্টা করুন:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

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

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

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


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

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

2

;)

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

সুতরাং আমার এমভিসি / এইচএমভিসির কাঠামোর কাঠামোটি এর মতো দেখাচ্ছে:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

এছাড়াও আমার যদি প্রয়োজন হয় আমি মডিউল লাইব্রেরি, i18n বা সাহায্যকারীগুলিতে যুক্ত করব।

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

সুতরাং আপনার যা প্রয়োজন তা খুঁজে পাওয়া ভার্চির সহজ এবং দ্রুত।


1

সমস্যা: দীর্ঘ নাম (ফোরাম_মোডেল_ফর্ম)

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

ফাইল সিস্টেম অনুসন্ধান (কোন ফোল্ডারে ফোরামের মডেল রয়েছে?)।

এটি সিস্টেমটি কীভাবে প্রয়োগ করা হয়েছে তার উপর নির্ভর করে তবে ফাইল সিস্টেমের কাঠামো সাধারণত একটি কনভেনশন অনুসরণ করে যা বিস্তৃত ফাইল সিস্টেম অনুসন্ধান ব্যতীত সঠিক উপাদানটিতে তাত্ক্ষণিকভাবে অ্যাক্সেসের অনুমতি দেয়।

এখানে একটি উদাহরণ দেওয়া আছে, ধরুন ফোরামের উপাদানটি ব্যবহার করতে হবে:

তথ্য:

  • উপাদান-নাম: ফোরাম
  • নিয়ামক-নাম: সূচক

    $ কন্ট্রোলার_পথ = বেসডির। 'মডিউল /'। $ উপাদান_নাম। '/ নিয়ামক /'। $ নিয়ামক_নাম। '.Php';

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


সত্যিই, পিছনের দিকগুলি ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনগুলির মতো নয় যা দ্রুত শুরু করা দরকার, রান সময়টি সঠিকভাবে কনফিগার করার জন্য তারা প্রয়োজনীয় সময় নিতে পারে। ভাল যুক্তি.
প্যাট্রিক হিউজ

0

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

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


0

আমি নিজে নিজে একটি ফ্রেমওয়ার্কে কাজ করছি এবং মডিউল ভিত্তিক এবং ফ্রি-ফর্ম ডিরেক্টরি কাঠামো উভয়ের সংমিশ্রণটি ব্যবহার করছি। ফ্রেমওয়ার্ক ব্যবহার করে সাইট কোডের জন্য আমার ডিফল্ট কাঠামোটি হ'ল:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

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

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


0

এর উত্তর পিএসআর -0 প্রস্তাব দ্বারা নির্ধারিত হয়েছে যা সমস্ত বৃহত সিস্টেমগুলি খাপ খাইয়ে শুরু করছে বা এখন গ্রহণ করেছে।

কাঠামোটি হ'ল:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

এর অর্থ এই যে দীর্ঘ ফাইলের নাম ঠিক করতে আপনি কিছুই করতে পারবেন না:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

এর অর্থ হ'ল আপনাকে সমস্ত ছোট হাতের পরিবর্তে বোবা মিক্সড-কেস ফাইলগুলি ব্যবহার করতে হবে (যদি আপনি তৃতীয় পক্ষের লাইব্রেরিগুলি কাজ না করে)।


0

ম্যাথিয়াসেস সলিউশনটি দুর্দান্ত ধারণা দেয় এবং তার ফোল্ডার কাঠামোটি ব্যবহারের ফলে প্লাগযোগ্য উপকরণগুলি প্রতিরোধ করা যায় না, উদাহরণস্বরূপ একটি স্বতন্ত্র / গ্যালারী যুক্ত করা / এটি দেখতে দেখতে পারে

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

এখন আমাদের একটি ভাগ করা "মডেল" এবং প্রয়োজনে স্বতন্ত্র একটি রয়েছে

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