Як ви організовуєте рамку MVC, підтримуючи модулі / плагіни? [зачинено]

Є дві основні структури кодових баз, які я бачив, коли мова йде про рамки MVC. Проблема полягає в тому, що вони, схоже, мають організаційну помилку, яка йде разом із ними.

Стандартний MVC

/controller
/model
/view

Проблема: Відсутність поділу пов'язаних компонентів (форум, блог, користувач тощо)

Модульний MVC

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

Вибір системи на базі модулів залишає перед вами проблему.

• Довгі імена (Forum_Model_Forum = форум / модель / forum.php) (як Zend)
• Файлова система здійснює пошук, is_file()щоб знайти, яку папку має модель форуму? (Як Кохана)

Чи є їхні інші структури MVC, які добре працюють при спробі розділити різні модулі? Чи є користь від цих структур, які мені не вистачає?

Спробуйте:

/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
    ....

Це повинно зробити зрозумілим, що у вас може бути кілька клієнтів, які всі так чи інакше взаємодіють з однією моделлю.

;)

Я знайшов найкращу структуру для MVC / HMVC Framework разом. Для основних потрібно використовувати базові контролери / моделі / представлення ... але для окремих компонентів модулів курсу ...

Тож у моїй структурі MVC / HMVC виглядає приблизно так:

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

Також якщо мені потрібно, я додаю в бібліотеки модулів, i18n або помічників.

Конвенція іменування проста, для контролерів та моделей я додаю суфікси _Controller та _Model. Для контролерів та моделей із модулів я також додаю префікс із назвою модуля, напр. Профіль контролера в модулі Користувач буде названий як User_Profile_Controller.

Тож вірно легко і швидко знайти те, що вам потрібно.

Проблема: Довгі імена (Forum_Model_Forum)

Систематичне називання класів допомагає уникнути конфліктів між іменами між компонентами. Тривале називання класів, ймовірно, не накладає суворих штрафних санкцій. Я вважаю цю схему іменування досить корисною при кодуванні, оскільки легко зрозуміти, що звідки походить.

пошук файлової системи (яка папка має модель форуму?).

Це дуже залежить від того, як система була впроваджена, але структура файлової системи зазвичай дотримується конвенції, яка дозволяє негайно отримати доступ до правильного компонента без широкого пошуку файлової системи.

Ось приклад, припустимо, що слід використовувати компонент форуму:

Інформація:

• Назва компонента: форум

• Ім'я контролера: індекс

  $ controller_path = BASEDIR. 'модуль /'. $ компонент_ім'я. '/ контролер /'. $ ім'я_контролера. '.php';

Також важливо зазначити, що при завантаженні типового веб-сайту існує буквально сотні запитів файлової системи, тому додавання деяких не зашкодить.

У мене є робота з веб-сайтами, які розпочалися з першого «Стандартного MVC», але з часом стали «Модульним MVC».

Якщо ви робите невеликий веб-сайт і не маєте великого досвіду, можливо, ви захочете почати зі "Стандартного MVC". Якщо ви вже знаєте, що веб-сайт буде дуже складним і великим, то вам доведеться звикнути до "Модульного MVC", це буде трохи важко на початку, але, зрештою, ви звикнете це.

Насправді я сам працюю над рамкою і використовую комбінацію структури, що базується на модулі, та вільної форми. Моя структура за замовчуванням для коду сайту з використанням фреймворку:

/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)

Ви також можете мати папку модулів, яка не відноситься до контролера, і є одна за замовчуванням виклик Core, яка використовується для зберігання широких шаблонів сайту, як заголовок і колонтитул. Це мені дає найкраще з обох світів. Ви можете легко знати, де знаходиться контролер, оскільки в папці є один контролер, але для класів, таких як моделі, вам не потрібно шукати, де файли є такими, як вони знаходяться в одній папці (що також зберігає назви моделей чистішими) .

Спосіб завантаження файлів дещо відрізняється, оскільки я дозволяю користувачеві налаштовувати різні каталоги, де можуть бути класи, тому я спочатку розбираю каталоги та зберігаю всі файли класів у файлі json, а потім використовую для швидкого пошуку всі інші запити (хоча я шукаю шляхи покращення цього).

Відповідь на це було продиктовано пропозицією PSR-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

Це також означає, що вам доведеться використовувати німі файли змішаного регістру замість усіх малих регістрів (якщо ви не працюєте сторонніми бібліотеками).

Рішення Mathiases має великий сенс І використання його структури папок не заважає мати вміст, що підключається, наприклад додавання незалежної / галереї / може виглядати так

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

Тепер у нас є спільна "модель" та незалежна, якщо це необхідно