คุณจะจัดระเบียบกรอบงาน MVC ของคุณในขณะที่สนับสนุนโมดูล / ปลั๊กอินได้อย่างไร [ปิด]

17

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบ เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ

ปิดให้บริการใน6 ปีที่ผ่านมา

มีโครงสร้าง codebase หลักสองที่ฉันได้เห็นเมื่อมันมาถึงกรอบ MVC ปัญหาคือพวกเขาทั้งสองดูเหมือนจะมีข้อผิดพลาดขององค์กรที่ไปกับพวกเขา

MVC มาตรฐาน

/controller
/model
/view

ปัญหา: ไม่มีการแยกส่วนประกอบที่เกี่ยวข้อง (ฟอรัมบล็อกผู้ใช้ ฯลฯ )

MVC แบบแยกส่วน

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

การเลือกระบบที่ใช้โมดูลทำให้คุณมีปัญหา

ชื่อยาว (Forum_Model_Forum = forum / model / forum.php) (Like Zend)
ระบบไฟล์ค้นหาโดยใช้is_file()เพื่อค้นหาว่าโฟลเดอร์ใดมีรุ่นฟอรัมหรือไม่ (เช่นเดียวกับ Kohana)

โครงสร้าง MVC อื่น ๆ ของพวกเขานั้นทำงานได้ดีเมื่อพยายามแยกโมดูลที่แตกต่างกันหรือไม่? มีประโยชน์จากโครงสร้างเหล่านี้ที่ฉันขาดไปหรือไม่?

— Xeoncross
แหล่งที่มา

1

ฉันต้องการเพิ่มว่าฉันต้องการโครงสร้างที่สอดคล้องกับ PSR-0ดังนั้นฉันจึงสามารถใช้ห้องสมุดเช่น Zend และ Doctrine ได้หากต้องการ

— Xeoncross

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

สิ่งนี้จะทำให้เห็นได้ชัดว่าคุณสามารถมีลูกค้าได้หลายรายซึ่งทั้งหมดนี้ไม่ทางใดก็ทางหนึ่งมีปฏิสัมพันธ์กับแบบจำลองเดียว

— Mathias Verraes
แหล่งที่มา

+1 เพราะฉันเห็นด้วยอย่างยิ่งกับคำอธิบายของคุณเกี่ยวกับองค์ประกอบ MVC และวิธีการใช้งาน อย่างไรก็ตามจุดของโมดูลคือคุณสามารถนำเข้าโมดูลที่สร้างโดยผู้ใช้รายอื่นดังนั้นการมีโมเดลนอกเส้นทางของโมดูลจะทำให้ "ลากแล้วปล่อย" น้อยลง อย่างไรก็ตามวิธีการของคุณเหมาะสมสำหรับแอปพลิเคชันที่ไม่ได้ใช้ปลั๊กอินหรือโมดูลภายนอก

— Xeoncross

@ Xeoncross นั้นเป็นความจริงฉันไม่ได้คำนึงถึงความสามารถในการนำกลับมาใช้จริงที่นี่ หากเป็นข้อกำหนดคุณสามารถไปอีกขั้นหนึ่งได้และมีตัวอย่างเช่นโมดูล 'ผู้ใช้' ที่จัดกลุ่มโมเดลผู้ใช้ด้วยตัวควบคุมและโมดูลบล็อกที่จัดกลุ่มรุ่นบล็อกโพสต์และความคิดเห็นด้วยตัวควบคุม และเช่นเคย: ขึ้นอยู่กับบริบท :-)

— Mathias Verraes

2

;)

ฉันพบโครงสร้างที่ดีที่สุดสำหรับ 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 สำหรับตัวควบคุมและรุ่นจากโมดูลฉันยังเพิ่มคำนำหน้าด้วยชื่อโมดูลเช่น Profile controller ในโมดูลผู้ใช้จะถูกตั้งชื่อเป็น User_Profile_Controller

ดังนั้นจึงเป็นเรื่องง่ายและรวดเร็วในการค้นหาสิ่งที่คุณต้องการ

— โชกุน
แหล่งที่มา

1

ปัญหา: ชื่อยาว (Forum_Model_Forum)

การตั้งชื่ออย่างเป็นระบบของคลาสช่วยหลีกเลี่ยงความขัดแย้งในการตั้งชื่อระหว่างส่วนประกอบ การตั้งชื่อแบบยาวของคลาสไม่น่าจะทำให้เกิดการลงโทษที่รุนแรง ฉันพบว่ารูปแบบการตั้งชื่อนี้ค่อนข้างมีประโยชน์เมื่อเขียนโค้ดเพราะมันง่ายที่จะดูว่าอะไรมาจากที่ไหน

การค้นหาระบบไฟล์ (โฟลเดอร์ใดมีรุ่นฟอรัม)

สิ่งนี้ขึ้นอยู่กับวิธีการนำระบบมาใช้ แต่โครงสร้างของระบบไฟล์มักจะเป็นไปตามข้อตกลงที่อนุญาตให้เข้าถึงส่วนประกอบที่ถูกต้องได้ทันทีโดยไม่ต้องค้นหาระบบไฟล์อย่างกว้างขวาง

นี่คือตัวอย่างสมมติว่าคอมโพเนนต์ฟอรัมใช้:

ข้อมูล:

ชื่อส่วนประกอบ: ฟอรัม
ชื่อคอนโทรลเลอร์: ดัชนี

$ controller_path = BASEDIR 'โมดูล/' . $ component_name '/ controller /' $ controller_name '.php';

นอกจากนี้ยังเป็นสิ่งสำคัญที่จะต้องทราบว่ามีการสืบค้นระบบไฟล์หลายร้อยตัวเมื่อทำการบู๊ตเว็บไซต์ทั่วไปดังนั้นการเพิ่มบางอย่างจะไม่ทำให้เกิดความเสียหาย

— ทุ่งหญ้าแห้ง
แหล่งที่มา

แท้จริงแล้วแบ็คเอนด์ไม่เหมือนแอปฝั่งไคลเอ็นต์ที่ต้องเริ่มต้นอย่างรวดเร็วพวกเขาสามารถใช้เวลาที่จำเป็นในการกำหนดค่าเวลาทำงานอย่างเหมาะสม จุดดี.

— Patrick Hughes

0

ฉันทำงานกับเว็บไซต์ที่เริ่มต้นด้วย "Standard MVC" เครื่องแรก แต่ในที่สุดก็กลายเป็น "Modular MVC"

หากคุณกำลังทำเว็บไซต์ขนาดเล็กและไม่มีประสบการณ์มากนักคุณอาจต้องการเริ่มต้นด้วย "Standard MVC" หากคุณรู้อยู่แล้วว่าเว็บไซต์นั้นมีความซับซ้อนและมีขนาดใหญ่คุณจะต้องคุ้นเคยกับ "Modular MVC" มันจะเป็นการยากที่จะเริ่มต้น แต่ในที่สุดคุณจะคุ้นเคยกับ มัน.

— umlcat
แหล่งที่มา

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)

นอกจากนี้คุณยังสามารถมีโฟลเดอร์โมดูลที่ไม่เกี่ยวข้องกับตัวควบคุมและมีหนึ่งโดยเรียกคอร์เริ่มต้นที่ใช้ในการจัดเก็บแม่แบบทั้งเว็บไซต์เช่นส่วนหัวและส่วนท้าย สิ่งนี้สำหรับฉันได้ให้สิ่งที่ดีที่สุดของทั้งสองโลก คุณสามารถรู้ได้อย่างง่ายดายว่าคอนโทรลเลอร์อยู่ที่ไหนเพราะมีคอนโทรลเลอร์หนึ่งตัวต่อหนึ่งโฟลเดอร์ แต่สำหรับคลาสเช่นรุ่นคุณไม่จำเป็นต้องค้นหาว่าไฟล์อยู่ที่ไหนภายใต้ไดเรกทอรีเดียว .

วิธีที่ฉันโหลดไฟล์แตกต่างกันเล็กน้อยเนื่องจากฉันอนุญาตให้ผู้ใช้กำหนดค่าไดเรกทอรีต่าง ๆ ที่ซึ่งคลาสอาจเป็นดังนั้นฉันแยกไดเรกทอรีเริ่มแรกและจัดเก็บตำแหน่งไฟล์คลาสทั้งหมดในไฟล์ json แล้วใช้เพื่อค้นหาอย่างรวดเร็ว คำขออื่น ๆ ทั้งหมด (แม้ว่าฉันกำลังมองหาวิธีในการปรับปรุงนี้)

— ryanzec
แหล่งที่มา

0

คำตอบสำหรับเรื่องนี้ได้รับการกำหนดโดยข้อเสนอ 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

นอกจากนี้ยังหมายความว่าคุณต้องใช้ไฟล์ผสมตัวพิมพ์เล็ก ๆ แทนตัวพิมพ์เล็กทั้งหมด (หากคุณไม่ใช้ไลบรารี่ของบุคคลที่สามจะไม่ทำงาน)

— Xeoncross
แหล่งที่มา

0

วิธีการแก้ปัญหาทางคณิตศาสตร์ทำให้รู้สึกที่ดีและการใช้โครงสร้างโฟลเดอร์ของเขาไม่ได้ป้องกันการมีเนื้อหา pluggable เช่นการเพิ่มอิสระ / แกลเลอรี่ / อาจมีลักษณะเช่นนี้

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

ตอนนี้เรามี "โมเดล" ที่แชร์และอิสระถ้าจำเป็น

— ติโม Huovinen
แหล่งที่มา