เนื้อหา
ถามฉันว่าจะใช้กรอบงานไหนและฉันอาจจะมีช่วงเวลาที่หญิงชราไม่พอใจและบอกคุณว่ากรอบงานทั้งหมดนั้นแย่พอ ๆ กัน ซึ่งไม่ได้หมายความว่าพวกเขาทั้งหมดไม่ดี แต่ใน PHP เรามีเฟรมเวิร์กจำนวนมากอย่างไม่น่าเชื่อ (โดยปกติจะอ้างว่าเป็น N + 1 โดยที่ N คือจำนวนนักพัฒนา PHP ในโลก) และพวกเขาทั้งหมดอาจสมเหตุสมผล ให้กับผู้ที่คิดค้นสิ่งเหล่านี้ขึ้นมา
การเลือกเฟรมเวิร์กนั้นน่าจะดีกว่าการพยายามใช้เฟรมเวิร์กเพียงเฟรมเดียวไม่ว่าคุณจะพยายามสร้างอะไรก็ตามเพราะมันเป็นเฟรมเวิร์กที่ "ดีที่สุด" (ไม่ว่าจะวัดผลว่า "ดีที่สุด" ก็ตาม) การเลือกข้อเสนอเฟรมเวิร์กนี้หมายความว่าคุณสามารถเลือกสิ่งที่ตรงกับความต้องการของโครงการและอาจจัดทำเป็นเอกสาร เฟรมเวิร์กบนแพลตฟอร์มใด ๆ มีไว้เพื่อจัดเตรียมโครงสร้างโมดูลและไลบรารีที่ใช้ซ้ำได้และโดยทั่วไปจะหลีกเลี่ยงงานที่น่าเบื่อและซ้ำซากที่เกี่ยวข้องกับการสร้างฟังก์ชันเดิมซ้ำแล้วซ้ำเล่า ตัวอย่างเช่นเมื่อสร้าง CMS บางสิ่งบางอย่างควรประมวลผลและตรวจสอบความถูกต้องของฟิลด์ในแบบฟอร์มให้ฉัน หากปล่อยทิ้งไว้ในอุปกรณ์ของตัวเองฉันอาจพลาดบางสิ่งที่สำคัญและฉันค่อนข้างจะทำองค์ประกอบของแต่ละโครงการที่เป็นอยู่ แตกต่างกันแทนที่จะเป็นสิ่งที่เหมือนกันทุกครั้ง!
เฟรมเวิร์กแบบเต็มสแต็ก
เฟรมเวิร์กแบบเต็มสแต็กเช่น Zend Framework อาจเป็นจุดเริ่มต้นที่ดีสำหรับนักพัฒนาที่ไม่มีประสบการณ์ด้านสถาปัตยกรรมมากนัก มันให้โครงสร้างที่ดีในการแขวนแอปพลิเคชันใหม่และมี "ระบบนิเวศ" ที่ดีอยู่รอบตัวมีหนังสือบทแนะนำและเอกสารประกอบที่เหมาะสมอีกมากมาย หากคุณกำลังพยายามสร้างแอปพลิเคชันขนาดใหญ่ซึ่งจะได้รับการดูแลโดยผู้คนจำนวนมากดังนั้นเฟรมเวิร์กที่เป็นที่นิยมและครอบคลุมน่าจะเป็นทางเลือกที่ดีเนื่องจากจะกำหนดโครงสร้างจำนวนมากและเป็นที่รู้จักและเข้าใจกันดี
การมีโครงสร้างเพื่อช่วยในการแยกเป็นสิ่งที่ดีเสมอ ในช่วงต้นอาชีพของฉันฉันทำงานกับบางคน มาก นักพัฒนารุ่นเยาว์และพยายามสอนรูปแบบ MVC (Model View Controller) ให้กับพวกเขาซึ่งค่อนข้างใหม่ในเวลานั้น เราได้ตัดสินใจใช้ Smarty ในเลเยอร์มุมมอง ส่วนหนึ่งเพื่อให้นักออกแบบทำงานกับเทมเพลตได้ง่ายขึ้นและอีกส่วนหนึ่งคือเมื่อมีคนมาที่โต๊ะทำงานของฉันแล้วพูดว่า "ฉันจะ X กับ Smarty ได้อย่างไร" ฉันพูดได้ว่า "อย่าทำ X ในมุมมอง!" (เก้าคูณ 10 นั่นคือคำตอบ) การมีเฟรมเวิร์กช่วยให้เราพบการแบ่งแยกเดียวกันในส่วนอื่น ๆ ของแอปพลิเคชันของเรา หลายคนสนับสนุนการรวมเข้ากับเลเยอร์เทมเพลตเช่น Smarty หรือ Twig โปรดใหม่ของฉันดังนั้นคุณสามารถนำเครื่องมือเหล่านั้นติดตัวไปได้ไม่ว่าจะใช้กรอบงานใดก็ตามที่คุณเลือก
แบ่งเบาภาระ
มีเฟรมเวิร์กที่เบากว่า Zend Framework มากมายเช่นฉันทำงานกับ CodeIgniter ไม่น้อย ครอบคลุมและแข็งแกร่งพอ ๆ กับ Zend Framework หรือไม่ ไม่มันไม่ใช่ แต่ในฐานะที่เป็นกรอบงานตัวช่วยที่ช่วยให้สร้างแอปพลิเคชันได้อย่างรวดเร็วจึงมีประโยชน์ โดยทั่วไปแล้วเฟรมเวิร์กที่มีฟังก์ชัน "ตัวช่วย" น้อยจะสามารถค้นหาเส้นทางของคุณได้ง่ายขึ้นเนื่องจากจะเห็นได้ชัดเจนมากขึ้นว่าชิ้นส่วนต่างๆเข้ากันได้อย่างไร ในเฟรมเวิร์กที่ไม่คุ้นเคย (สำหรับฉันนั่นคือทุกอย่างจริงๆ) มันเป็นบิตอัตโนมัติที่ทำให้ยากต่อการทำงานและแก้ไขข้อบกพร่อง
ความรู้สึก "หลงอยู่ในกรอบใหม่" นั้นเป็นสิ่งที่หลีกเลี่ยงไม่ได้และน่าหงุดหงิดอย่างที่สุด แม้แต่นักพัฒนาที่มีประสบการณ์ก็ยังรู้สึกเหมือนเป็นมือใหม่เมื่อไม่รู้ว่าอะไรทำงานอย่างไร หากคุณโชคไม่ดีจริงๆคุณจะต้องเลือกกรอบงานที่ช่อง IRC จะบอกคุณว่าคุณก็งี่เง่าเช่นกัน! นี่เป็นประสบการณ์เริ่มต้นเชิงลบที่ทำให้ผู้คนจำนวนมากเลิกใช้กรอบงานใหม่หรือการนำมาใช้ตั้งแต่แรกและมีเพียงไม่กี่เฟรมเวิร์กเท่านั้นที่ช่วยผู้ใช้ใหม่ให้พ้นจากอุปสรรคในช่วงแรกนั้นได้
ใน PHP เรายังมีเฟรมเวิร์กบางอย่างที่ไม่ใช่เฟรมเวิร์กแบบที่ฉันมักจะใช้คำนี้ เรามีกรอบองค์ประกอบที่น่ารัก คอลเลกชันของไลบรารีที่ออกแบบมาเพื่อให้ใช้งานได้ตามต้องการและเล่นร่วมกันได้อย่างสวยงามเช่น Zeta Components (ก่อนหน้านี้ eZ Components) และ Symfony Components (คุณเคยเห็นไซต์ของพวกเขาหรือไม่พวกเขาได้รับรางวัลสำหรับงานศิลปะที่ดีที่สุด!) สิ่งที่ดีที่สุดและต่ำที่สุดของสิ่งเหล่านี้คือข้อเสนอ PEAR และ PECL ของ PHP เองซึ่งสิ่งเหล่านี้จะถูกลืมไปในโลกแห่งกรอบใหม่ที่กล้าหาญนี้
ไมโครเฟรมเวิร์ค
Microframeworks เป็นเทรนด์ที่เกิดขึ้นใหม่ใน PHP สิ่งเหล่านี้เป็นข้อเสนอที่มีน้ำหนักเบาเป็นพิเศษซึ่งช่วยให้คุณเชื่อมต่อสิ่งต่างๆเข้าด้วยกันได้เร็วขึ้น ตัวอย่างที่ดีคือ Slim ซึ่งรวดเร็วและใช้งานง่ายมากและเข้าใจแนวคิด RESTful มันขึ้นอยู่กับแนวคิดของ "เส้นทาง" ซึ่งเป็นรูปแบบ URL คุณลงทะเบียนเส้นทางและโทรกลับซึ่งควรเรียกใช้เมื่อมีการร้องขอ URL นั้น
นักพัฒนา PHP ส่วนใหญ่ใช้เฟรมเวิร์กและยึดติดกับมันหรืออาจใช้อย่างใดอย่างหนึ่งในที่ทำงานและอีกอันสำหรับงานอดิเรกหรือโปรเจ็กต์โอเพ่นซอร์ส มีความเห็นเป็นเอกฉันท์เพียงเล็กน้อยเกี่ยวกับเฟรมเวิร์กที่ "ดีที่สุด" ที่จะใช้ดังนั้นทุกคนจึงยึดติดกับสิ่งที่พวกเขารู้และผลลัพธ์ก็คือการพัฒนาเฟรมเวิร์กจำนวนมหาศาลแบบคู่ขนาน ฉันชอบที่จะมีตัวเลือกให้เลือก แต่ฉันพูดถึงว่าพวกเขาเลวร้ายพอ ๆ กันหรือไม่?
ถ้าคุณรู้จัก Zend Framework แล้วคุณจะอธิบายว่าตัวเองเป็นนักพัฒนา Zend Framework ได้ คุณคงไม่สบายใจที่จะเขียนในเฟรมเวิร์กอื่นจนกว่าคุณจะมีโอกาสได้จับมันและคุณอาจจำฟังก์ชัน PHP ดิบหลายอย่างไม่ได้หากคุณไม่ได้ใช้บ่อยๆ ความคิดที่ว่าเรากลายเป็นนักพัฒนาเฉพาะเฟรมเวิร์คซึ่งทำงานเฉพาะบนเลเยอร์ของนามธรรมเป็นเรื่องแปลกสำหรับ PHP ท้ายที่สุดนี่คือภาษา "เพื่อแก้ปัญหาเว็บ" มันเขียนด้วยภาษา C และเป็นภาษาที่รวดเร็วและเบาในตัว ... โดยที่คุณไม่ต้องรอให้กระบวนการ bootstrap ของเฟรมเวิร์กขนาดใหญ่ทำงาน! จากบริบทดังกล่าวทำให้ MicroPHP Manifesto เขียนโดยชายคนหนึ่งที่เราเรียกว่า Funkatron (แม้ว่าชื่อของเขาจะเป็น Ed Finkler จริงๆก็ตาม) เป็นชุดคำแถลงที่บอกว่าการสร้างโมดูลขนาดเล็กที่ทำงานร่วมกันได้เป็นเรื่องปกติที่ใหญ่กว่านั้นไม่ดีกว่าและจริงๆแล้วชีวิตก็สั้นเกินไปสำหรับ Java แม้ว่าจะเขียนด้วย PHP ก็ตาม
