สำหรับปีที่ผ่านมาฉันได้ทำงานกับชุดของแอปพลิเคชันทั้งหมดตามกรอบ Zend และเน้นที่ตรรกะทางธุรกิจที่ซับซ้อนซึ่งแอปพลิเคชันทั้งหมดต้องเข้าถึงได้แม้ว่าจะไม่ได้ใช้ทั้งหมด (ง่ายกว่าการมีโฟลเดอร์ไลบรารีหลายโฟลเดอร์สำหรับแต่ละโฟลเดอร์ แอปพลิเคชันที่เชื่อมโยงทั้งหมดกับศูนย์ส่วนกลาง)
โดยไม่ต้องลงรายละเอียดมากนักเกี่ยวกับโครงการที่เฉพาะเจาะจงฉันกำลังมองหาข้อมูล (ขณะที่ฉันกำลังทำงานในโครงการเพียงอย่างเดียว) ว่าฉันมี "จัดกลุ่ม" รหัสของฉันอย่างไร ฉันได้พยายามแยกมันออกมาในลักษณะที่จะลบการพึ่งพาได้มากที่สุด
ฉันพยายามที่จะเก็บมันไว้อย่างอิสระเท่าที่ฉันจะทำได้อย่างมีเหตุมีผลดังนั้นในเวลา 12 เดือนเมื่อเวลาของฉันเพิ่มขึ้นใครก็ตามที่เข้ามาไม่มีปัญหาในการขยายสิ่งที่ฉันสร้างขึ้น
โครงสร้างตัวอย่าง:
applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)
applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)
applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)
applicationStorage\Tests\ (contains PHP unit tests)
applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)(หมายเหตุ: โฟลเดอร์โมดูลการกำหนดค่าการเลย์เอาต์และ ZendExtended จะทำซ้ำในแต่ละโฟลเดอร์แอปพลิเคชัน แต่ฉันได้ละไว้เนื่องจากไม่จำเป็นสำหรับวัตถุประสงค์ของฉัน)
สำหรับไลบรารีจะมีรหัส "สากล" ทั้งหมด กรอบ Zend เป็นหัวใจของแอปพลิเคชันทั้งหมด แต่ฉันต้องการให้ตรรกะทางธุรกิจของฉันเป็นอิสระจาก Zend โมเดลและอินเตอร์เฟส mapper ทั้งหมดไม่มีการอ้างอิงสาธารณะถึง Zend_Db แต่จริง ๆ แล้วล้อมรอบเป็นส่วนตัว
ดังนั้นความหวังของฉันคือในอนาคตฉันจะสามารถเขียน mappers และ dbtables (ประกอบด้วย Models_DbTable_Abstract ที่ขยาย Zend_Db_Table_Abstract) เพื่อแยกตรรกะทางธุรกิจของฉันออกจากกรอบ Zend สภาพแวดล้อมที่ไม่ใช่กรอบ Zend (อาจเป็นบางกรอบ PHP อื่น ๆ )
การใช้ serviceLocator และการลงทะเบียนบริการที่ต้องการภายใน bootstrap ของแต่ละแอปพลิเคชันฉันสามารถใช้เวอร์ชันเดียวกันของบริการเดียวกันได้ขึ้นอยู่กับคำขอและแอปพลิเคชันใดที่กำลังเข้าถึงอยู่
ตัวอย่าง: แอปพลิเคชันภายนอกทั้งหมดจะมีการลงทะเบียน service_auth_External service_auth_Interface
เหมือนกันกับ aplications ภายในกับ Service_Auth_Internal การนำ service_auth_Interface Service_Locator :: getService ('Auth')
ฉันกังวลว่าฉันอาจพลาดปัญหาที่เป็นไปได้เกี่ยวกับเรื่องนี้
สิ่งหนึ่งที่ฉันนึกถึงคือไฟล์ config.ini สำหรับภายนอกทั้งหมดจากนั้นแอปพลิเคชันแยกต่างหาก config.ini จะแทนที่หรือเพิ่มลงใน config.ini ภายนอกทั่วโลก
หากใครมีข้อเสนอแนะใด ๆ ฉันจะขอบคุณอย่างมาก
ฉันได้ใช้การสลับบริบทสำหรับฟังก์ชั่น AJAX ภายในแต่ละแอปพลิเคชัน แต่มีโอกาสใหญ่ทั้งภายนอกและภายในจะได้รับบริการเว็บที่สร้างขึ้นสำหรับพวกเขา อีกครั้งสิ่งเหล่านี้จะถูกแยกออกเนื่องจากการอนุญาตและบริการที่แตกต่างกัน
\applicationstorage\Applications\internal\webservice
\applicationstorage\Applications\external\webservice