มันสมเหตุสมผลหรือไม่ที่จะหลีกเลี่ยงเฟรมเวิร์กเมื่อสร้าง webapp ขนาดใหญ่ด้วย PHP?

ในฐานะนักพัฒนาแอปพลิเคชันเว็บ PHP เป็นเวลาหลายปีฉันมีส่วนแบ่ง MVC และกรอบงานของฉัน ตอนแรกฉันคิดว่าพวกเขาเป็นสิ่งที่ดีที่สุดตั้งแต่หั่นขนมปัง; ทุกอย่างดูเหมือนจะง่ายมากที่จะใช้

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

ตัวอย่างเช่นในหนึ่งในโครงการของฉันที่ฉันใช้ Slim (C) + Idiorm (M) + Twig (V) (ซึ่งฉันเชื่อว่ามีความยืดหยุ่นมาก) ฉันต้องสร้างฟังก์ชันที่กำหนดเองเพื่อแสดงข้อมูลแบบไดนามิกในเทมเพลตหลัก ไม่มีกรอบฉันสามารถรัน mysql_query () ในไฟล์ที่รวมไว้ได้

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

แต่จริงๆแล้วสำหรับเว็บแอปพลิเคชันที่ซับซ้อนเช่นระบบจัดการโรงเรียนแบบ all-in-one เว็บกรอบมักจะได้รับในทางของกระบวนการทางธุรกิจของฉันเช่นในตัวอย่างข้างต้น

ดังนั้นคำถามของฉันคือ: ใช่ไหมที่จะกลับไปสู่พื้นฐานและใช้รหัส PHP มาตรฐานและ libaries ในการทำโปรเจ็กต์ต่อไปของฉันซึ่งอาจมีกรอบและไลบรารีที่มีค่าใช้จ่ายสูงถึงพันล้านหากฉันสามารถใช้วิธีการเขียนโค้ดที่ดี ชอบ MVC ไหม ทีมพัฒนาของฉันค่อนข้างเล็ก: มีเพียงโปรแกรมเมอร์ 2 คนและนักออกแบบ 1 คน โปรแกรมเมอร์คนอื่นเห็นด้วยกับความคิดของฉันด้านบน

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

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

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

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

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

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

ประสบการณ์ของฉันกับ "เฟรมเวิร์ก" ฝั่งเซิร์ฟเวอร์ค่อนข้างไม่เป็นที่พอใจตัวอย่างเช่น:

A) Jar file hell ที่เฟรมเวิร์กขัดแย้งกันหรือเซิร์ฟเวอร์แอพสำหรับสิ่งที่เข้ากันไม่ได้และคุณไม่ต้องการรู้อะไรและไม่อยู่ในตำแหน่งที่จะบอกต่อเพราะมันจะป้องกันไม่ให้คุณปรับใช้ เซิร์ฟเวอร์หลายเครื่อง

B) การระเบิดอย่างหายนะของการสร้างวัตถุที่ง่ายที่สุดในการประมวลผล SQL ที่ไม่จำเป็นหลายพันรายการ

C) แนวคิดที่แปลกประหลาดที่การเข้ารหัส XML 100 บรรทัดนั้นง่ายกว่าหรือน่าเชื่อถือกว่าการเข้ารหัส Java 2 บรรทัด

D) ความจำเป็นในการเขียน 100s ของบรรทัดของ POJOS ฝั่งเซิร์ฟเวอร์ที่ไม่จำเป็นอย่างสมบูรณ์เพื่อแมปไปยังวัตถุฝั่งไคลเอ็นต์ในภาษาอื่นหรือบางครั้งก็มีหลายภาษาอื่น ๆ (C # JS ฯลฯ )

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

เป็นคนทรยศเขียนกรอบของคุณเอง ... คุณจะไม่เสียใจตราบใดที่คุณวางแผนที่จะกำจัดสิ่งที่ไม่จำเป็นทั้งหมดที่คนอื่นหลอกให้คุณคิดว่าคุณต้องการ จากนั้นคุณจะเข้าใจมันทั้งหมดมันจะจัดส่งเป็น Kb แทนที่จะเป็น Mb และมันอาจจะ "รันได้ทุกที่" ซึ่งเป็นหนึ่งในหลักการก่อตั้งของ Java ใช่ไหม?

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

มีวิธีการนำเสนอย้อนกลับจากผู้พัฒนา Django ซึ่งฉันมีปัญหาในการค้นหาในตอนนี้ แต่พวกเขาพูดถึง "หุบเขาแห่งประสิทธิภาพ" ที่กรอบทำให้คุณมีประสิทธิผลมากขึ้น

สมมติว่าคุณไม่มีความรู้เกี่ยวกับกรอบเมื่อคุณเริ่มต้นโครงการผลผลิตของคุณเริ่มแรกจะต่ำมาก - คุณจะได้เรียนรู้หลักการของกรอบการทำงานมากกว่าที่จะเป็นสำนวนของภาษา (ซึ่งหวังว่าคุณจะรู้แล้ว)

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

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

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

ดังนั้นสำหรับโครงการขนาดเล็ก (จากประสบการณ์ของฉันไม่มีอะไรภายใต้ ~ 500 ชั่วโมง) ประสิทธิภาพของคุณที่มีกรอบจะยิ่งใหญ่กว่ามีประสิทธิภาพโดยไม่ต้อง เมื่อคุณได้รับเกณฑ์ที่แน่นอน (ระหว่าง 500 ถึง 800 ชั่วโมง, IME) จากนั้นคุณเริ่มตระหนักว่ามีข้อ จำกัด ในสิ่งที่เฟรมเวิร์กสามารถนำเสนอได้

จากที่กล่าวมาเฟรมเวิร์กให้ประโยชน์มากกว่าแค่ประสิทธิภาพ - เฟรมเวิร์กเช่น Symfony หรือ Django หรือ (ฉันกำลังสมมติ) Rails จัดให้มีการประชุมที่อนุญาตให้ทีมทำงานแบบไดนามิกและยังช่วยให้ลูกค้าหรือเจ้าของผลิตภัณฑ์เปลี่ยนพนักงานโดยไม่ต้อง ทรัพยากรใหม่เพื่อเรียนรู้ระบบใหม่อย่างสมบูรณ์ - หากพวกเขาคุ้นเคยกับแบบแผนของกรอบงานและปฏิบัติตามอนุสัญญานั้นพวกเขาจะมีประสิทธิผลมากกว่าในตอนแรก

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

ต้องบอกว่าวันนี้กรอบ Zend ดูเหมือนจะเป็นที่นิยมอย่างดุเดือดในวันนี้และสุจริต? ฉันดิ้นรนเพื่อดูว่าทำไมบางครั้ง ฉันต้องทำงานกับมันในอดีตและฉันไม่ได้ชอบสถาปัตยกรรมของมันสักหน่อย คลาส Zend_Form ถูกปรับแต่งอย่างน่าขันระบบตกแต่งภายในของมันน่าสยดสยองที่สุดในการใช้งานและมัณฑนากรเชื่อมโยงกับรูปแบบเพื่อทำลายแนวคิดของ OOP ที่ระบุว่าวัตถุควรอยู่คู่กันอย่างหลวม ๆ นอกจากนี้ยังมีรหัสจำนวนมากที่นำมาใช้เป็น Singletones (ซึ่งไม่ดีสำหรับเหตุผลที่มีการบันทึกไว้อย่างดีดังนั้นฉันจะไม่ย้ำอีกครั้ง) และวัตถุ Registry ยังมีส่วนช่วยกระตุ้นสไตล์การเขียนโค้ดที่เลอะเทอะ

ฉันได้ยินมาว่า Zend Framework 2 (ปัจจุบันอยู่ในรุ่นเบต้า) เป็นผลิตภัณฑ์ที่ดีกว่ามาก แต่รสชาติที่ไม่ดีของ Zend 1 ที่เหลืออยู่ในปากของฉันหมายความว่าฉันไม่ต้องรีบลองเลย

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

สิ่งที่คุณอธิบายได้ถูกเรียกว่า "ความซับซ้อนที่เกิดจากสิ่งที่เป็นนามธรรม" ในอดีต บทความเดียวในการจัดการคือ: การจัดการความซับซ้อนที่เป็นนามธรรมโดย David Keppel Keppel แนะนำว่าเฟรมเวิร์กมีการออกแบบที่ทำให้เกิดความซับซ้อนที่เป็นนามธรรม

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

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

บรรทัดล่างคือสิ่งนี้การใช้เฟรมเวิร์กขนาดใหญ่สำหรับโครงการง่าย ๆ (เช่นการแสดงบางฟิลด์จากฐานข้อมูล) บางครั้งอาจเกินขีด จำกัด ได้ สำหรับโครงการขนาดใหญ่หรือซับซ้อนให้ใช้เฟรมเวิร์ก

มีหลาย ๆ ด้านในการเขียนโค้ดของคุณเทียบกับการใช้ Framework:

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

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

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

ฉันมักจะโต้แย้งด้วย "การจัดการ" เพื่อใช้ Symfony2 เพราะมันเป็นกรอบสำหรับการพัฒนาเว็บ ฝ่ายบริหารคิดว่ามันใหญ่แล้วมันจะเสียค่าใช้จ่ายและต้องหลีกเลี่ยงโปรแกรมเมอร์เพราะช่วงการเรียนรู้สูงชัน

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

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