Cómo lograr un mejor desacoplamiento en PHP
Para los marcos PHP tradicionales, es difícil extraer componentes que deben usarse por separado del marco. Porque el componente puede usar objetos Logger, objetos Config y otros objetos, y estas dependencias externas están escritas en el código fuente. A veces, si desea utilizar una determinada función solo en el marco, debe escribir mucho código de transferencia. Para implementar un marco PHP altamente desacoplado, debe consultar los dos patrones de ubicación del servicio e inyección de dependencia. En Zend framework2.0, la capa inferior implementa DI y la capa superior encapsula un ServiceManager según SL.
Algunas personas dicen que Service Locator es un antipatrón, porque el uso de Service Locator en el código también se considera una dependencia externa implícita. De hecho, esto es pretencioso, ¿el uso de un contenedor IoC en su código no es una dependencia externa? El problema es utilizar el patrón correcto en el contexto correcto.
Primero, debe averiguar si el código pertenece a la "persona que llama" o al "llamado". Como "llamado", como un módulo, se espera que su código se use en diferentes ocasiones. Por supuesto, cuanto menor sea el acoplamiento con el exterior, mejor para las interfaces externas que necesita. " a Inyección pasiva; pero para el código de "llamador" del "llamador", como código de capa de aplicación final, debe poder darse cuenta de la situación global. Por supuesto, es inevitable acoplarse directamente con cada componente.
En cuanto a cuándo usar la inyección de dependencia y cuándo usar la orientación de servicio, mi opinión personal es la siguiente: al escribir un componente, es mejor usar el patrón de inyección de dependencia, especialmente cuando este componente puede usarse en diferente Cuando se usa en ingeniería de proyectos; al escribir código de capa de aplicación o plataformas de proyectos que están fuertemente relacionados con componentes, se puede usar el modelo orientado a servicios. Además, la interfaz externa de inyección de dependencia tiene una fuerte dependencia del componente. Sin estas interfaces externas, el componente no puede ejecutarse de forma independiente; la interfaz externa obtenida por la orientación del servicio tiene una dependencia débil sin estas interfaces externas, el componente básicamente no puede ejecutarse. . Por ejemplo, el componente del modelo de usuario utilizará dos interfaces externas durante el proceso de registro del usuario. Una es la interfaz de la capa de acceso a datos, que se utiliza para guardar la información del usuario en una base de datos u otro medio de almacenamiento permanente. se utiliza para enviar mensajes a Se envía una carta de confirmación de registro a la dirección de correo electrónico del usuario. La interfaz de la capa de acceso a datos tiene una fuerte dependencia del componente del modelo de usuario. Sin el primero, el segundo no funcionará; mientras que la interfaz de correo electrónico tiene una débil dependencia del componente del modelo de usuario, sin esta interfaz, el proceso de registro del usuario también puede funcionar. completado. Sólo aparecerán algunos mensajes de advertencia.