Symfony 4: แนวทางปฏิบัติที่ดีที่สุด

เวอร์ชันหลักใด ๆ ของโครงการคือโอกาสในการทบทวนแนวทางปฏิบัติที่ดีที่สุด พวกเขาทันสมัย ปรับให้เข้ากับคุณสมบัติใหม่ของโครงการ Symfony 4 ไม่มีข้อยกเว้น

มาตรฐานก่อน

Symfony 4 จะเป็นวิวัฒนาการของแนวทางปฏิบัติปัจจุบันพยายามที่จะใช้เครื่องมือมาตรฐานเพิ่มเติม

Symfony มุ่งมั่นที่จะใช้มาตรฐานของ PHP และเว็บ เป็นเรื่องยากที่จะเชื่อว่า Symfony 2 เริ่มต้นในเวลาที่ไม่มีนักแต่งเพลง ตั้งแต่นั้นมาชุมชน PHP เริ่มต้นกลุ่ม Fig ซึ่งใช้คำแนะนำหลายอย่าง Symfony เป็นหนึ่งในเฟรมเวิร์กหลักแรกที่ใช้ PSR ส่วนใหญ่โดยไม่ทำลายความเข้ากันได้แบบย้อนหลัง PSR-3 สำหรับการบันทึกเป็นเวลาหลายปีที่ผ่านมา PSR-4 สำหรับการโหลดอัตโนมัติ อีกไม่นาน PSR-6 สำหรับการแคช รุ่นถัดไปของ Symfony เวอร์ชัน 3.3 ใช้ PSR-16 สำหรับการแคชและ PSR-11 ใหม่ล่าสุดสำหรับการทำงานร่วมกันของคอนเทนเนอร์ เราอาจมีกรณีการใช้งานสำหรับ PSR-13

การใช้มาตรฐานช่วยในการทำงานร่วมกัน แต่ยังมีการแยกรหัสของคุณออกจากกรอบงาน

แอปพลิเคชันแบบไม่รวมชุด

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

ตัวแปรสภาพแวดล้อม

หนังสือแนวทางปฏิบัติที่ดีที่สุดของ Symfony ปัจจุบันอธิบายอย่างละเอียดถึงวิธีการสร้างการตั้งค่าการกำหนดค่าในแอปพลิเคชัน Symfony เมื่อใดควรใช้ app / config / parameters.yml สำหรับการกำหนดค่าที่เกี่ยวข้องกับโครงสร้างพื้นฐานหรือ app / config / config.yml สำหรับการกำหนดค่าที่เกี่ยวข้องกับแอปพลิเคชัน

ฉันจะไปไกลเท่าที่แนะนำเพื่อหลีกเลี่ยงการใช้แอพ / config / config.yml ให้มากที่สุด มีกรณีการใช้ที่ถูกต้อง แต่ฉันสามารถนับได้ด้วยมือเดียว

Symfony 4 จะไม่เทียบเท่า app / config / parameters.yml ใช้ตัวแปรสภาพแวดล้อมแทน นี่คือสิ่งที่กรอบการทำงานส่วนใหญ่ทำในภาษาอื่น นี่เป็นหนึ่งในคำแนะนำของ 12-Factor Application Manifesto หนึ่งที่ได้รับการสนับสนุนจากแพลตฟอร์มโฮสต์ที่ทันสมัยหลายแห่ง

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

โปรดทราบว่าการเก็บความลับในตัวแปรสภาพแวดล้อมนั้นไม่“ ปลอดภัย” มากกว่าการเก็บไว้ในไฟล์การกำหนดค่า

เนื่องจากการใช้ตัวแปรสภาพแวดล้อมอาจยุ่งยากในการพัฒนาการใช้ไฟล์ "มาตรฐาน" .env จึงง่ายและแนะนำ Symfony 3.3 มาพร้อมกับองค์ประกอบ Dotenv ใหม่ที่จะใช้เป็นค่าเริ่มต้นในแอปพลิเคชัน Symfony 4 การสลับระหว่างไฟล์. env และตัวแปรสภาพแวดล้อม "ของจริง" จะกระทำโดยอัตโนมัติและโปร่งใส

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

ในฐานะที่เป็นผลข้างเคียงที่ดีมันช่วยลดความซับซ้อนของสภาพแวดล้อม Symfony และการตั้งค่าสถานะการดีบักโดยทั้งคอนโซลและเว็บแอปพลิเคชัน

ปัจจุบันเครื่องมือคอนโซล Symfony สามารถใช้สภาวะแวดล้อมและแฟล็ก debug ผ่านแฟล็ก --env และ --no-debug หรืออีกวิธีหนึ่งผ่านตัวแปรสภาวะแวดล้อม SYMFONY_ENV และ SYMFONY_DEBUG

ด้วย Symfony 4 สิ่งนี้ไม่จำเป็นอีกต่อไป APP_ENV และ APP_DEBUG สามารถใช้ได้ทั้งตัวควบคุมหน้าเว็บและเครื่องมือคอนโซล

ไม่มี. / bin/console foo: bar --env = prod - no-debug หรือ SYMFONY_ENV = prod SYMFONY_DEBUG = 0 ./bin/console foo: bar เพียงใช้. / bin/console foo: bar

มันใช้งานได้ ในการพัฒนาและบนเซิร์ฟเวอร์การผลิต

Symfony 4 เต็มไปด้วยความเรียบง่ายเช่นนี้

Unified Web Front Controller

Symfony 3 มีตัวควบคุมหน้าเว็บสองตัว หนึ่งที่เหมาะสำหรับการผลิต หนึ่งที่เหมาะสำหรับการพัฒนา Symfony 4 ใช้เพียงหนึ่งเดียว ไม่จำเป็นต้องลบตัวควบคุมหน้าเว็บการพัฒนาอีกต่อไป ไม่มีปัญหาด้านความปลอดภัยอีกต่อไปหากคุณลืม

คุณคิดว่ารหัสนั้นซับซ้อนกว่า แต่ก่อน นี่ไม่ใช่กรณีที่เราสามารถลบรหัส“ ดั้งเดิม” จำนวนมากได้ ขอบคุณตัวแปรสภาพแวดล้อม ขอบคุณ PHP 7 และการลบ bootstrap และคลาสแคช ขอบคุณ Symfony 3.3 ที่ไม่จำเป็นต้องใช้โปรแกรมโหลดอัตโนมัติเฉพาะ

Makefile

หลายโครงการมีสคริปต์ที่กำหนดเอง: เสื้อคลุมสำหรับเรียกใช้การทดสอบหน่วยหรือการรวมสคริปต์ที่รันเซิร์ฟเวอร์ในตัว PHP และอื่น ๆ สคริปต์ที่เขียนคำสั่งคอนโซล Symfony จะไม่สมเหตุสมผล

เพื่อความสะดวกคุณอาจกำหนดไว้ในไฟล์ application composer.json ของคุณ Silex ทำเช่นนั้นด้วยรายการสคริปต์ที่รันเซิร์ฟเวอร์ในตัว PHP แต่นั่นมาพร้อมกับปัญหามากมายเช่นหมดเวลาหรือไม่รองรับ ANSI escape code

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

make เป็นเครื่องมือ "มาตรฐาน" ที่รู้จักกันดี มันมีประสิทธิภาพมากกว่าสคริปต์ที่ดำเนินการโดย Composer มันไม่ได้พึ่งพา PHP ใช้เพื่อความสะดวกในการปรับใช้เพื่อเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลผ่าน SSH เพื่อเรียกใช้การทดสอบ Blackfire ใช้มันเพื่อรัน npm, gulp, webpack คุณตั้งชื่อมัน งานที่ใช้คำสั่ง Symfony นั้นไม่เหมาะสมหรือไม่พึงประสงค์

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

ลองยกตัวอย่างหนึ่งการล้างแคช Symfony มีคำสั่งให้ล้างและอุ่นแคช การทำทั้งสองอย่างในกระบวนการเดียวกันนั้นใช้ไม่ได้ผลเพราะ PHP ไม่สามารถโหลดคลาสได้หากมีการเปลี่ยนแปลง แต่นี่เป็นเรื่องง่ายที่จะทำให้สำเร็จด้วยการทำ:

แคชชัดเจน
  @test -f bin / console && bin / console cache: clear - no-warmup || rm -rf var / cache / *
.PHONY: ล้างแคช
cache-warmup: cache-clear
  @test -f bin / console && bin / console cache: warmup || echo "ไม่สามารถอุ่นแคช (ต้องการ symfony / console)"
.PHONY: แคชการอุ่นเครื่อง

เป็นอีกตัวอย่างหนึ่งโครงการ PHP ส่วนใหญ่ของฉันมีสองงานที่ช่วยทำการทดสอบ Blackfire:

BF-dev:
   blackfire-player --endpoint = http: // `เซิร์ฟเวอร์ bin / console: สถานะ --filter = address` run ทดสอบ / bkf / all.bkf
.PHONY: bf-dev
BF-แยง:
  blackfire-player --endpoint = https: //twig.sensiolabs.org เรียกใช้การทดสอบ / bkf / all.bkf --variable = "env = prod"
.PHONY: bf-prod

ต้องการเปลี่ยนเป็นแอปพลิเคชันเป็นโหมด "บำรุงรักษา" หรือไม่ ใช้ make ไม่ใช่คำสั่ง Symfony

การจัดการสินทรัพย์

Assetic ถูกลบออกใน Symfony Standard Edition 3.0 ขณะนี้เราไม่แนะนำให้เปลี่ยนใด ๆ เนื่องจากโลก JavaScript ยังคงทำงานกับเครื่องมือ "มาตรฐาน" แต่ Symfony 4 จะให้คำแนะนำและมอบการรวมที่ล้ำลึก เพิ่มเติมเกี่ยวกับที่ในไม่กี่สัปดาห์ ถึงกระนั้นฉันอยากจะพูดถึงมันในขณะที่เรายังสนับสนุนสินทรัพย์ที่มีการเชื่อมโยง / คัดลอกจากชุดข้อมูลไปยังเว็บ / ชุดรวม / ผ่านสินทรัพย์: ติดตั้ง แต่นั่นอาจเป็นสิ่งที่ไม่สามารถอยู่รอดได้ Symfony 5 โดยเฉพาะอย่างยิ่ง ตอนนี้

การสนับสนุนแนวปฏิบัติที่ดีที่สุดแบบใหม่มีผลกระทบต่อโครงสร้างไดเรกทอรีซึ่งหัวข้อของโพสต์ถัดไป คอยติดตาม!

เผยแพร่ครั้งแรกที่ fabien.potencier.org