Làm thế nào để bạn tổ chức khung MVC của bạn trong khi hỗ trợ các mô-đun / plugin? [đóng cửa]


17

Có hai cấu trúc cơ sở mã chính mà tôi đã thấy khi nói đến các khung công tác MVC. Vấn đề là cả hai dường như có một lỗi tổ chức đi cùng với họ.

MVC chuẩn

/controller
/model
/view

Vấn đề: Không tách các thành phần liên quan (diễn đàn, blog, người dùng, v.v.)

Mô-đun MVC

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

Chọn hệ thống dựa trên mô-đun khiến bạn gặp vấn đề.

  • Tên dài (Forum_Model_Forum = forum / model / forum.php) (Giống như Zend)
  • Tìm kiếm hệ thống tập tin bằng cách sử dụng is_file()để tìm thư mục nào có mô hình diễn đàn? (Giống như Kohana)

Có bất kỳ cấu trúc MVC nào khác hoạt động tốt khi cố tách các mô-đun khác nhau không? Có những lợi ích từ các cấu trúc mà tôi đang thiếu?


1
Tôi cũng muốn thêm rằng tôi muốn một cấu trúc tuân thủ PSR-0 để tôi cũng có thể sử dụng các thư viện như Zend và Doctrine nếu cần.
Xeoncross

Câu trả lời:


9

Thử:

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

Mô hình của bạn là trái tim của ứng dụng của bạn. Bạn nên thiết kế và mã hóa chúng như một gói độc lập. Các bộ điều khiển chỉ là khách hàng của mô hình của bạn, điều đó xảy ra để chuyển hoạt động của người dùng thành hành động cho mô hình của bạn. Một khung nhìn chỉ là một cách hiển thị dữ liệu cụ thể từ mô hình của bạn. Nếu ứng dụng của bạn phát triển, bạn có thể tiến xa hơn trong việc tách khách hàng khỏi mô hình:

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

/model
    User
    BlogPost
    Comment
    ....

Điều này sẽ làm rõ rằng bạn có thể có nhiều khách hàng, tất cả theo cách này hay cách khác, tương tác với một mô hình duy nhất.


+1 vì tôi hoàn toàn đồng ý với lời giải thích của bạn về các thành phần MVC và cách chúng hoạt động. Tuy nhiên, điểm quan trọng của một mô-đun là bạn có thể nhập các mô-đun được tạo bởi người dùng khác để có các mô hình bên ngoài đường dẫn mô-đun làm cho nó bớt "kéo và thả". Tuy nhiên, phương pháp của bạn rất có ý nghĩa đối với các ứng dụng không sử dụng các plugin hoặc mô-đun bên ngoài.
Xeoncross

@Xeoncross đó là sự thật, tôi chưa thực sự tính đến việc sử dụng lại ở đây. Nếu đó là một yêu cầu, bạn thực sự có thể tiến thêm một bước và ví dụ như mô-đun 'Người dùng' nhóm mô hình Người dùng với bộ điều khiển của nó và mô-đun Blog nhóm mô hình BlogPost và Nhận xét với các bộ điều khiển của nó. Như mọi khi: nó phụ thuộc vào ngữ cảnh :-)
Mathias Verraes

2

;)

Tôi đã tìm thấy cấu trúc tốt nhất cho Khung MVC / HMVC kết hợp. Đối với chính, bạn cần sử dụng bộ điều khiển / mô hình / khung nhìn cơ bản ... nhưng đối với các thành phần riêng lẻ của các mô-đun khóa học ...

Vì vậy, trong cấu trúc khung MVC / HMVC của tôi trông như thế này:

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

Ngoài ra nếu tôi cần tôi thêm vào các thư viện mô-đun, i18n hoặc người trợ giúp.

Quy ước đặt tên rất dễ dàng, đối với các bộ điều khiển và mô hình tôi thêm hậu tố _Contoder và _Model. Đối với các bộ điều khiển và mô hình từ các mô-đun, tôi cũng thêm một tiền tố với tên mô-đun, ví dụ như. Cấu hình bộ điều khiển trong mô-đun Người dùng sẽ được đặt tên là User_Profile_Contoder.

Vì vậy, thật dễ dàng và nhanh chóng để tìm thấy những gì bạn cần.


1

Vấn đề: Tên dài (Forum_Model_Forum)

Đặt tên có hệ thống của các lớp giúp tránh đặt tên xung đột giữa các thành phần. Việc đặt tên dài của các lớp không có khả năng áp dụng hình phạt hiệu suất nghiêm trọng. Tôi thấy sơ đồ đặt tên này khá hữu ích khi mã hóa bởi vì thật dễ dàng để xem những gì đến từ đâu.

tìm kiếm hệ thống tập tin (thư mục nào có mô hình diễn đàn?).

Điều này phụ thuộc rất nhiều vào cách hệ thống được triển khai, nhưng cấu trúc của hệ thống tệp thường tuân theo một quy ước cho phép truy cập ngay vào thành phần chính xác mà không cần tìm kiếm hệ thống tệp rộng rãi.

Dưới đây là một ví dụ, giả sử thành phần diễn đàn sẽ được sử dụng:

Thông tin:

  • Tên thành phần: diễn đàn
  • Tên bộ điều khiển: chỉ mục

    $ control_path = BASEDIR. 'mô-đun /'. $ thành phần tên. '/ bộ điều khiển /'. $ control_name. '.php';

Ngoài ra, điều quan trọng cần lưu ý là có hàng trăm truy vấn hệ thống tệp khi khởi động một trang web thông thường, vì vậy việc thêm một số sẽ không gây hại.


Quả thực, back end không giống như các ứng dụng phía máy khách cần khởi động nhanh, chúng có thể mất thời gian cần thiết để định cấu hình thời gian chạy chính xác. Điểm tốt.
Patrick Hughes

0

Tôi đã làm việc với các trang web bắt đầu với "Standard MVC" đầu tiên, nhưng cuối cùng, trở thành "Modular MVC".

Nếu bạn đang làm một trang web nhỏ và không có nhiều kinh nghiệm, bạn có thể muốn bắt đầu với "MVC tiêu chuẩn". Nếu bạn đã biết rằng trang web sẽ rất phức tạp và lớn, thì bạn sẽ phải làm quen với "Modular MVC", nó sẽ hơi khó khăn khi bắt đầu, nhưng, cuối cùng, bạn sẽ quen với nó


0

Tôi thực sự đang làm việc trên một khung công tác và sử dụng kết hợp cả hai cấu trúc thư mục dựa trên mô-đun và dạng tự do. Cấu trúc mặc định của tôi cho mã trang web sử dụng khung là:

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

Bạn cũng có thể có một thư mục mô-đun không liên quan đến bộ điều khiển và có một lệnh gọi mặc định Core được sử dụng để lưu trữ các mẫu rộng của trang web như đầu trang và chân trang. Điều này với tôi cung cấp tốt nhất của cả hai thế giới. Bạn có thể dễ dàng biết bộ điều khiển ở đâu vì có một bộ điều khiển cho mỗi thư mục nhưng đối với các lớp như mô hình bạn không cần tìm kiếm nơi chứa các tệp như trong một thư mục (cũng giữ tên của các mô hình sạch hơn) .

Cách tôi tải tệp hơi khác một chút vì tôi cho phép người dùng định cấu hình các thư mục khác nhau ở nơi các lớp có thể để tôi phân tích các thư mục ban đầu và lưu trữ tất cả các vị trí tệp lớp trong tệp json và sau đó sử dụng để tìm nhanh tất cả các yêu cầu khác (mặc dù tôi đang tìm cách cải thiện điều này).


0

Câu trả lời cho điều này đã được đưa ra bởi Đề xuất PSR-0 mà tất cả các hệ thống lớn đang bắt đầu thích nghi hoặc đã được áp dụng ngay bây giờ.

Cấu trúc là:

\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

Điều này có nghĩa là bạn không thể làm gì để sửa tên tệp dài:

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

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

Điều này cũng có nghĩa là bạn phải sử dụng các tệp hỗn hợp câm thay vì tất cả chữ thường (nếu bạn không thư viện của bên thứ ba sẽ không hoạt động).


0

Giải pháp Mathiases rất có ý nghĩa Và việc sử dụng cấu trúc thư mục của anh ấy không ngăn cản việc có nội dung có thể cắm được, ví dụ như thêm một bộ sưu tập / độc lập / có thể trông như thế này

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

Bây giờ chúng tôi có một "mô hình" được chia sẻ và những mô hình độc lập nếu cần thiết

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.