ເນື້ອຫາ
ຖາມຂ້ອຍວ່າໂຄງຮ່າງໃດທີ່ຈະໃຊ້ແລະຂ້ອຍອາດຈະມີແມ່ຍິງເຖົ້າທີ່ຂີ້ຕົວະແລະບອກເຈົ້າວ່າທຸກໆກອບແມ່ນບໍ່ດີຄືກັນ. ເຊິ່ງບໍ່ໄດ້ ໝາຍ ຄວາມວ່າພວກເຂົາທຸກຢ່າງບໍ່ດີ, ແນ່ນອນ, ແຕ່ໃນ PHP ພວກເຮົາມີກອບ ຈຳ ນວນຫລາຍທີ່ບໍ່ຄາດຄິດ (ມັກຈະຖືກກ່າວເຖິງ N + 1, ບ່ອນທີ່ N ແມ່ນຕົວເລກຂອງນັກພັດທະນາ PHP ໃນໂລກ), ແລະພວກເຂົາທັງ ໝົດ ອາດຈະມີຄວາມ ໝາຍ. ກັບບຸກຄົນທີ່ຄິດຄົ້ນພວກເຂົາ.
ມີທາງເລືອກຂອງກອບແມ່ນອາດຈະດີກ່ວາທີ່ຈະພະຍາຍາມໃຊ້ພຽງກອບດຽວ, ບໍ່ວ່າທ່ານຈະພະຍາຍາມກໍ່ສ້າງ, ເພາະວ່າມັນແມ່ນສິ່ງທີ່ດີທີ່ສຸດ (ໂດຍມາດຕະການໃດ ໜຶ່ງ ຂອງ 'ດີທີ່ສຸດ'). ການຄັດເລືອກເອົາຂໍ້ສະ ເໜີ ກອບນີ້ ໝາຍ ຄວາມວ່າທ່ານສາມາດເລືອກເອົາສິ່ງທີ່ຕອບສະ ໜອງ ຄວາມຕ້ອງການຂອງໂຄງການແລະມັນອາດຈະແມ່ນເອກະສານ. ກອບຕ່າງໆໃນເວທີໃດກໍ່ມີຢູ່ໃນການສະ ໜອງ ໂຄງສ້າງ, ໂມດູນແລະຫໍສະ ໝຸດ ທີ່ໃຊ້ຄືນໄດ້, ແລະໂດຍທົ່ວໄປຫລີກລ້ຽງທຸກໆວຽກທີ່ ໜ້າ ເບື່ອແລະຊ້ ຳ ແລ້ວທີ່ຈະເຮັດກັບການກໍ່ສ້າງ ໜ້າ ທີ່ດຽວກັນຢູ່ເລື້ອຍໆ. ຕົວຢ່າງເຊັ່ນເມື່ອສ້າງ CMSes, ບາງສິ່ງບາງຢ່າງຄວນຈະປະມວນຜົນແລະເຮັດແບບຟອມທີ່ຖືກຕ້ອງ ສຳ ລັບຂ້ອຍ; ຖ້າປ່ອຍໃຫ້ອຸປະກອນຂອງຂ້ອຍເອງຂ້ອຍອາດຈະຄິດຮອດສິ່ງທີ່ ສຳ ຄັນແລະຂ້ອຍມັກຈະເຮັດສ່ວນປະກອບຂອງແຕ່ລະໂຄງການ ແຕກຕ່າງ, ກ່ວາສິ່ງທີ່ຄ້າຍຄືກັນທຸກໆຄັ້ງ!
ກອບເຕັມຮູບແບບ
ກອບທີ່ເຕັມຮູບແບບເຊັ່ນ Zend Framework ສາມາດເປັນບ່ອນທີ່ດີທີ່ຈະເລີ່ມຕົ້ນ ສຳ ລັບນັກພັດທະນາໂດຍບໍ່ມີປະສົບການດ້ານສະຖາປັດຕະຍະ ກຳ. ມັນສ້າງໂຄງສ້າງທີ່ດີໃນການວາງສະ ໝັກ ໃໝ່, ແລະມີ "ລະບົບນິເວດ" ທີ່ດີອ້ອມຮອບມັນ - ມີປື້ມ, ປື້ມແນະ ນຳ ແລະເອກະສານທີ່ສົມເຫດສົມຜົນບາງຢ່າງເຊັ່ນກັນ. ຖ້າທ່ານ ກຳ ລັງພະຍາຍາມສ້າງໂປແກຼມໂປຼແກຼມຂະ ໜາດ ໃຫຍ່ເຊິ່ງຈະຖືກຮັກສາໄວ້ໂດຍຄົນ ຈຳ ນວນຫຼວງຫຼາຍ, ຫຼັງຈາກນັ້ນໂຄງຮ່າງການນິຍົມທີ່ສົມບູນແບບອາດຈະເປັນທາງເລືອກທີ່ດີເພາະມັນຈະ ກຳ ນົດໂຄງສ້າງທີ່ຂ້ອນຂ້າງຫຼາຍແລະເປັນທີ່ຮູ້ຈັກແລະເຂົ້າໃຈດີ.
ມີໂຄງສ້າງທີ່ຈະຊ່ວຍໃນການແຍກຕ່າງຫາກແມ່ນດີຕະຫຼອດເວລາ; ໃນຕົ້ນປີໃນອາຊີບຂ້ອຍເຮັດວຽກກັບບາງຄົນ ຫຼາຍ ນັກພັດທະນາ ໜຸ່ມ ແລະພະຍາຍາມສອນພວກເຂົາແບບແຜນ MVC (Model View Controller), ເຊິ່ງຂ້ອນຂ້າງ ໃໝ່ ໃນເວລານັ້ນ. ພວກເຮົາໄດ້ຕັດສິນໃຈໃຊ້ Smarty ໃນຊັ້ນເບິ່ງ; ບາງສ່ວນເພື່ອໃຫ້ນັກອອກແບບສາມາດເຮັດວຽກກັບແມ່ແບບໄດ້ງ່າຍຂຶ້ນ, ແລະບາງສ່ວນເພື່ອວ່າເມື່ອມີຄົນມາທີ່ໂຕະຂອງຂ້ອຍແລະເວົ້າວ່າ "ຂ້ອຍຈະເຮັດແນວໃດ X ກັບ Smarty?" ຂ້ອຍສາມາດເວົ້າວ່າ "ຢ່າເຮັດ X ໃນມຸມມອງ!" (ເກົ້າຄັ້ງຈາກ 10, ນັ້ນແມ່ນ ຄຳ ຕອບ). ມີກອບຕ່າງໆຊ່ວຍໃຫ້ພວກເຮົາຊອກຫາຄວາມແຕກຕ່າງກັນໃນພາກສ່ວນອື່ນໆຂອງການສະ ໝັກ ຂອງພວກເຮົາ. ພວກມັນ ຈຳ ນວນຫຼາຍສະ ໜັບ ສະ ໜູນ ການປະສົມປະສານກັບຊັ້ນ templating ເຊັ່ນ Smarty, ຫຼື Twig ໃໝ່ ທີ່ຂ້ອຍມັກ, ສະນັ້ນທ່ານສາມາດ ນຳ ໃຊ້ເຄື່ອງມືເຫຼົ່ານັ້ນກັບທ່ານທີ່ທ່ານເລືອກ.
ເຮັດໃຫ້ການໂຫຼດເບົາລົງ
ມີຫລາຍໆກອບທີ່ມີສີມ້ານກວ່າກອບ Zend Framework, ຍົກຕົວຢ່າງຂ້ອຍເຮັດວຽກກັບ CodeIgniter ຂ້ອນຂ້າງ ໜ້ອຍ. ມັນມີຄວາມສົມບູນແລະເຂັ້ມແຂງຄືກັບ Zend Framework ບໍ? ບໍ່, ມັນບໍ່ແມ່ນ. ແຕ່ໃນຖານະເປັນກອບຊ່ວຍເພື່ອຊ່ວຍໃຫ້ການສ້າງແອັບພລິເຄຊັນນັ້ນໄວ, ມັນມີປະໂຫຍດ. ໂດຍທົ່ວໄປແລ້ວ, ກອບທີ່ມີການເຮັດວຽກ 'ຜູ້ຊ່ວຍ' ໜ້ອຍ ກວ່າສາມາດຊອກຫາເສັ້ນທາງຂອງທ່ານໄດ້ງ່າຍຂື້ນເພາະມັນຈະແຈ້ງຂື້ນວ່າຕ່ອນເຫຼົ່ານັ້ນຢູ່ ນຳ ກັນແນວໃດ. ໃນກອບທີ່ບໍ່ຄຸ້ນເຄີຍ (ສຳ ລັບຂ້ອຍ, ນັ້ນແມ່ນສິ່ງທີ່ດີເລີດທັງ ໝົດ), ມັນແມ່ນການເຈາະລະບົບອັດຕະໂນມັດທີ່ເຮັດໃຫ້ມັນຍາກທີ່ຈະເຮັດວຽກກັບພວກເຂົາ.
ຄວາມຮູ້ສຶກທີ່ວ່າ "ສູນຫາຍໄປໃນກອບ ໃໝ່" ແມ່ນສິ່ງທີ່ຫລີກລ້ຽງບໍ່ໄດ້ແລະເຮັດໃຫ້ເຮົາ ໝົດ ຫວັງ; ແມ່ນແຕ່ນັກພັດທະນາທີ່ມີປະສົບການກໍ່ຮູ້ສຶກຄືກັບວ່າເປັນຄົນ ໃໝ່ ເມື່ອພວກເຂົາບໍ່ຮູ້ວ່າມີຫຍັງເຮັດວຽກແນວໃດ. ຖ້າທ່ານໂຊກດີແທ້ໆ, ທ່ານກໍ່ຈະໄດ້ເລືອກເອົາກອບທີ່ IRC ຈະບອກທ່ານວ່າທ່ານກໍ່ເປັນຄົນໂງ່ເຊັ່ນກັນ! ນີ້ແມ່ນປະສົບການໃນແງ່ລົບທີ່ເລີ່ມຕົ້ນທີ່ເຮັດໃຫ້ປະຊາຊົນ ຈຳ ນວນຫຼວງຫຼາຍບໍ່ຕ້ອງ ນຳ ໃຊ້ກອບ ໃໝ່ ຫຼືຮັບຮອງເອົາໃນອັນດັບ ທຳ ອິດ, ແລະຂອບເຂດ ຈຳ ນວນ ໜ້ອຍ ທີ່ເຮັດວຽກທີ່ດີໃນການຊ່ວຍເຫຼືອຜູ້ໃຊ້ ໃໝ່ ໃນບັນຫາດັ່ງກ່າວ.
ໃນ PHP ພວກເຮົາຍັງມີບາງກອບທີ່ບໍ່ມີກອບໃນແບບທີ່ຂ້ອຍມັກໃຊ້ ຄຳ ສັບ. ພວກເຮົາມີບາງກອບສ່ວນປະກອບທີ່ ໜ້າ ຮັກ; ການລວບລວມຫ້ອງສະ ໝຸດ ທີ່ຖືກອອກແບບມາເພື່ອ ນຳ ໃຊ້ແລະຈະຫລິ້ນຮ່ວມກັນຢ່າງງາມເຊັ່ນ: ອົງປະກອບ Zeta (ອົງປະກອບ eZ ກ່ອນ ໜ້າ ນີ້) ແລະສ່ວນປະກອບ Symfony (ທ່ານໄດ້ເຫັນເວັບໄຊຂອງພວກເຂົາບໍ? ພວກເຂົາຊະນະລາງວັນ ສຳ ລັບວຽກງານສິລະປະທີ່ດີທີ່ສຸດ!). ສິ່ງທີ່ດີທີ່ສຸດແລະ ສຳ ຄັນທີ່ສຸດຂອງສິ່ງເຫຼົ່ານີ້ແມ່ນແນ່ນອນ, ການສະ ເໜີ PEAR ແລະ PECL ຂອງ PHP ເອງ - ບາງຢ່າງເຫຼົ່ານີ້ຈະຖືກລືມໃນໂລກ ໃໝ່ ຂອງໂຄງຮ່າງທີ່ກ້າຫານນີ້.
Microframeworks
Microframeworks ແມ່ນທ່າອ່ຽງທີ່ພົ້ນເດັ່ນຂື້ນໃນ PHP; ເຫຼົ່ານີ້ແມ່ນເຄື່ອງຖວາຍທີ່ມີນ້ ຳ ໜັກ ເບົາທີ່ຊ່ວຍໃຫ້ທ່ານກາວສິ່ງຂອງຮ່ວມກັນໄດ້ໄວຂື້ນ. ຕົວຢ່າງທີ່ດີແມ່ນກະທັດຮັດ, ເຊິ່ງໃຊ້ໄດ້ໄວແລະລຽບງ່າຍ, ແລະເຂົ້າໃຈແນວຄິດ RESTful. ມັນແມ່ນອີງໃສ່ແນວຄວາມຄິດຂອງ 'ເສັ້ນທາງ', ເຊິ່ງແມ່ນຮູບແບບ URL. ທ່ານລົງທະບຽນເສັ້ນທາງແລະໃຫ້ການໂທຄືນເຊິ່ງຄວນຈະຖືກຮຽກຮ້ອງເມື່ອ URL ນັ້ນຖືກຮຽກຮ້ອງ.
ນັກພັດທະນາ PHP ສ່ວນໃຫຍ່ຮັບຮອງເອົາກອບແລະຕິດຢູ່ກັບມັນ, ຫຼືພວກເຂົາອາດຈະໃຊ້ວຽກໃນບ່ອນເຮັດວຽກແລະອີກບ່ອນ ໜຶ່ງ ສຳ ລັບວຽກອະດິເລກຫລືໂຄງການເປີດ. ມີຄວາມເຫັນດີເຫັນ ໜ້ອຍ ກ່ຽວກັບກອບ“ ດີທີ່ສຸດ” ທີ່ຈະ ນຳ ໃຊ້ສະນັ້ນທຸກຄົນພຽງແຕ່ຍຶດ ໝັ້ນ ໃນສິ່ງທີ່ພວກເຂົາຮູ້ແລະຜົນໄດ້ຮັບກໍ່ຄືການພັດທະນາແບບຂະ ໜານ ຂອງ ຈຳ ນວນກອບ ຈຳ ນວນມະຫາສານ! ຂ້ອຍຮັກທີ່ຈະມີການເລືອກທີ່ຈະເລືອກ, ແຕ່ຂ້ອຍໄດ້ບອກວ່າພວກເຂົາທັງ ໝົດ ເປັນຄົນຊົ່ວເທົ່າກັບຄົນອື່ນບໍ?
ຖ້າທ່ານຮູ້ Zend Framework ແລ້ວທ່ານຈົບການອະທິບາຍຕົວເອງວ່າເປັນນັກພັດທະນາ Zend Framework; ທ່ານຈະບໍ່ສະດວກໃນການຂຽນໃນກອບອື່ນຈົນກວ່າທ່ານຈະມີໂອກາດໄດ້ຮັບມືກັບມັນ, ແລະທ່ານອາດຈະບໍ່ຈື່ຫຼາຍ ໜ້າ ທີ່ PHP ທີ່ເປັນວັດຖຸດິບ ສຳ ລັບສິ່ງຕ່າງໆຖ້າທ່ານບໍ່ໃຊ້ມັນເລື້ອຍໆ. ຄວາມຄິດທີ່ວ່າພວກເຮົາກາຍເປັນນັກພັດທະນາລະບົບສະເພາະ, ພຽງແຕ່ເຮັດວຽກຢູ່ເທິງສຸດຂອງຊັ້ນຂອງການດຶງດູດ, ແມ່ນແປກ ສຳ ລັບ PHP. ຫຼັງຈາກທີ່ທັງ ໝົດ, ນີ້ແມ່ນພາສາທີ່ "ແກ້ໄຂບັນຫາເວັບ". ມັນຖືກຂຽນເປັນພາສາ C ແລະເປັນພາສາທີ່ໄວແລະເບົາໃນຕົວຂອງມັນເອງ ... ສະ ໜອງ ໃຫ້ທ່ານຢ່າລໍຖ້າຂະບວນການແລ່ນລົດເຂັນຂະ ໜາດ ໃຫຍ່ແລ່ນ! ຈາກສະພາບການນີ້ເກີດຂື້ນ MicroPHP Manifesto, ຂຽນໂດຍຜູ້ຊາຍທີ່ພວກເຮົາເອີ້ນວ່າ Funkatron (ເຖິງແມ່ນວ່າຊື່ຂອງລາວແມ່ນ Ed Finkler). ມັນແມ່ນຫລາຍໆ ຄຳ ສັ່ງທີ່ບອກວ່າມັນບໍ່ ເໝາະ ສົມທີ່ຈະສ້າງຫລາຍໂມດູນຂະ ໜາດ ນ້ອຍທີ່ສາມາດປ່ຽນແປງໄດ້, ທີ່ໃຫຍ່ກວ່ານັ້ນກໍ່ບໍ່ດີກວ່າ, ແລະທີ່ຈິງແລ້ວ, ຊີວິດມັນສັ້ນເກີນໄປ ສຳ ລັບ Java - ເຖິງແມ່ນວ່າມັນຈະຖືກຂຽນໄວ້ໃນ PHP.
