โครงสร้างองค์กร Application PHP ที่ฉลาด?

10

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

ในฐานะนักพัฒนา PHP ฉันสงสัยว่ามาตรฐานประเภทใดจะเริ่มปรากฎในโครงการหรือไม่ ด้วยPSR-0ในที่สุดเราก็มีมาตรฐานสำหรับการตั้งชื่อและการโหลดไฟล์ - แต่มันไม่มีความรู้ของฉันเกี่ยวกับส่วนประกอบที่เหลือซึ่งประกอบขึ้นเป็นระบบหรือวิธีการจัดการอย่างมีสติ

เรากำลังติดต่อกับ MVC เป็นอย่างมากดังนั้นตัวอย่างใดบ้างที่มีโครงการขนาดใหญ่ที่จัดการสิ่งเหล่านี้ได้อย่างถูกต้อง?

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

3

ในฐานะนักพัฒนา PHP คนอื่นฉันไม่คาดหวังว่า

— สติสัมปชัญญะ

2

@CamelBlues ขึ้นอยู่กับโอกาสที่บริสุทธิ์ผู้พัฒนา PHP บางคนต้องทำสิ่งที่ไม่เหมาะสมในที่สุดและทำสิ่งที่ถูกต้อง

— Xeoncross

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

— เจสัน

3

มันเป็นไปไม่ได้จริง ๆ ที่จะทำให้เป็นมาตรฐานว่าควรวางโครงการอย่างไรเพราะ "มันขึ้นอยู่กับ"

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

งานของเราในฐานะนักพัฒนาคือการมองหารูปแบบและแนวทางปฏิบัติที่ดีที่สุดและนำไปใช้กับงานในมือ เราใช้ประสบการณ์และความเชี่ยวชาญของเราในการเลือกโครงสร้างระบบไฟล์ที่เหมาะสมสำหรับโครงการที่เรากำลังดำเนินการ

— เฟนตัน
แหล่งที่มา

+1 โดยรวมแล้วฉันเห็นด้วยกับคุณนี่เป็นจุดที่ถูกต้องแน่นอน อย่างไรก็ตามหากคุณลบสิ่งต่าง ๆ นอกภาษา (โฟลเดอร์สำรองสคริปต์ cron / build สินทรัพย์คงที่และอื่น ๆ ) และเพียงแค่มุ่งเน้นไปที่ภาษาของตัวเอง - ฉันไม่เชื่อว่าสามารถสร้างอาร์กิวเมนต์เดียวกันได้ ภาษามีข้อ จำกัด ที่กำหนดไว้แล้ว การหาวิธีจัดคลาสและบล็อคโคดทั้งหมดของคุณเพื่อให้เหมาะสมสำหรับทุกโครงการเป็นเป้าหมายที่แท้จริงและบรรลุได้

— Xeoncross

0

ดูเหมือนจะไม่ได้มีความพยายามในการสร้างมาตรฐานมากนักและตามจริงแล้วฉันไม่เห็นประโยชน์ มีกฎเพียงข้อเดียวที่คุณควรปฏิบัติตามซึ่งก็คือคุณไม่ควรมีสิ่งใดภายใต้ docroot ที่ไม่ได้อยู่ในนั้น (ข้อควรระวังด้านความปลอดภัยขั้นพื้นฐาน)

นอกจากนั้นฉันจะไปกับสิ่งที่เหมาะสมสำหรับโครงการ

หากคุณใช้ MVC (ผ่านเฟรมเวิร์กหรือ ad-hoc) ดังนั้นโครงสร้างพื้นฐานที่มี / โมเดล / มุมมองและ / / คอนโทรลเลอร์จะเหมาะสม แต่แม้ว่าคุณจะไม่ได้คุณมักจะมีชั้นการเข้าถึงข้อมูลบางอย่างกับชั้นเรียนที่แมปไปยังหน่วยงานข้อมูลของคุณ มันสมเหตุสมผลที่จะมีไดเรกทอรีสำหรับสิ่งเหล่านั้น คุณมักจะมีคลาสของตรรกะทางธุรกิจและฟังก์ชันยูทิลิตี้มากมายดังนั้นไดเรกทอรีอื่น ๆ ถ้าคุณใช้ระบบแม่แบบแม่แบบไปยังไดเรกทอรีอื่น แล้วคุณอาจต้องการไดเรกทอรี 'ห้องสมุด' ซึ่งคุณใส่ห้องสมุดบุคคลที่สามทั้งหมด (เมื่อคุณมาถึงจุดนี้คุณก็กำลังทำ MVC อยู่แล้ว)

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

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

0

คุณสามารถติดตามโครงร่างโครงการสำหรับกรอบแอ็พพลิเคชันที่นิยมมากที่สุดสองรายการ:

Zend Framework - http://www.framework.zend.com/manual/en/project-structure.project.html
Symfony - http://symfony.com/doc/current/book/installation.html

สิ่งเหล่านี้จะให้โครงสร้างที่ขยายได้ตามแนวปฏิบัติที่ดีที่สุดและประสบการณ์จากผู้ใช้

— Stephen Senkomago Musoke
แหล่งที่มา