php - PDO+Singleton: ¿Por qué usarlo?
instance (1)
Esta pregunta ya tiene una respuesta aquí:
Leí en la web que muchos desarrolladores están usando el patrón de singleton para sus conexiones PDO. [¿dónde?]
He estado usando patrones de singleton antes (en VB.Net), y estoy bastante seguro de que solo es útil cuando tienes que llamar a una instancia dos veces o más [falta el código de ejemplo del código .NET].
Actualmente estoy trabajando en un sitio web de comercio electrónico, me gustaría saber si es realmente útil utilizar un patrón singleton en mis conexiones PDO ya que mi arquitectura está hecha de manera que cada script solo necesita una conexión [ejemplo de código donde usted usaría un singleton que faltaba].
En respuesta a la "discusión de comentarios" que ha encendido esta pregunta (y tal vez respuesta), un resumen de mi opinión y el consenso general (no escatime en equipo / carga del servidor, cuando eso significa duplicar las horas hombre y la capacidad de mantenimiento es más importante que la velocidad, excepto en algunos casos específicos).
Usted dice que odia los frameworks y que los desarrolladores que usan frameworks que ellos mismos no desarrollaron venden contratos de mantenimiento . ¿Cómo funciona eso exactamente? Cualquier persona que conozca el FW puede mantener el código utilizando un FW documentado de fuente abierta. Tu código puede ser mantenido por ti .
Además, los frameworks PHP son (bueno, los principales al menos) OPEN SOURCE . Sé que, viniendo de un fondo de VB.NET, podrías sospechar que hay una trampa para esto, pero realmente no es así. Todos tienen Repos de Github, la fuente está disponible para copiar y editar (de acuerdo con la licencia, que en general es bastante liberal). Básicamente, tienes el control total .
Y no piense que todo es código de segundo grado: Apple (incluidas las partes principales de su kernel OSX), Microsoft, Google ... todos usan software y marcos de código abierto. No solo porque es fácil y más rápido de desarrollar, sino también por la noción de tecnología comprobada .
Además: el rendimiento es tu objetivo y, dado que detestas los marcos, ¿por qué no considerar aprender a ensamblar ? De esta forma, puedes evitar que un compilador idiota compile tu código a algo que no es tan eficiente como, quizás, podría haber sido.
Y, por supuesto, no usas un IDE para esto, irías por Emacs o mariposas, ¿verdad?
Mariposa Emacs http://www.andreas-wilm.com/images/real_programmers_75p.png
Un enfoque alternativo sería usar un marco que ofrezca feeds de caché avanzados ...
La capacidad de mantenimiento debería ser lo más importante para usted, al escribir el código:
''La depuración es el doble de difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición, no es lo suficientemente inteligente como para depurarlo. - Brian Kernighan
Los servidores son zombis-esclavos: no se quejan, y no es ilegal azotarlos. Los desarrolladores, aunque algunos gerentes de proyecto parecen olvidar esto, no son ni zombis ni esclavos: no pueden trabajar 2 semanas seguidas, y los desarrolladores de azotes son ilegales, aún. Incluso Steve Ballmer sabe que ... Desarrolladores, Desarrolladores, Desarrolladores . Los sistemas operativos de servidor de Microsoft son intensivos en recursos, como MSSQL, y prácticamente todo su software, pero analice su sistema operativo de servidor. Hay muchas características que solo sirven para reducir las horas de mantenimiento que su sistema requiere . No soy un fanático de MS, pero entiendo completamente esa desición. No pueden vencer al precio de Linux (porque es gratis), pero pueden atraer a las empresas mediante la venta de un sistema, lo que reducirá a la mitad sus costos de administración de sistemas. (aunque, ATM, no han logrado esto, y OMI, nunca lo harán)
Esta pregunta es una de muchas trampas, una mala opción para SO, y se cerrará. Sin embargo, antes de que se cierre / elimine, me gustaría señalarle un par de cosas:
Primero lo primero :
Como actualmente estoy trabajando en un sitio web de comercio electrónico, me gustaría saber si es realmente útil utilizar un patrón singleton en mis conexiones PDO.
No, nunca lo es.
PHP no es capaz de persistir un estado de los objetos entre las solicitudes. El servidor recibe una solicitud. El script se analiza, se establece la conexión de DB, se realizan consultas, se envía de vuelta la respuesta y se cierra la conexión . Una y otra vez.
Las conexiones no se pueden serializar, no se pueden almacenar de ninguna manera, forma o forma, así que:
Al codificar bien, puede usar la inyección y, al mismo tiempo, asegurarse de que solo se conecta al DB una vez por solicitud.
Las estáticas son globales en la resistencia, ahora: ¿usarías globales si pudieras pasar una discusión? Te doy el beneficio de la duda, supongo que tu respuesta es no .
Los pocos beneficios restantes de los singleton que quedan, entonces, no justifican el esfuerzo que se necesita para escribir pruebas de unidad decentes y de trabajo para su código de uso de singleton.
Por qué ?
mi arquitectura está hecha de tal manera que cada script solo necesita una conexión.
Entonces tu código no es muy escalable. Sé que esta es una declaración general y un cliché terrible, pero simplemente es el caso aquí. Al igual que su presunción de que cada secuencia de comandos solo necesita una conexión podría ser cierto en este momento , pero ¿quién puede decir que siempre será el caso?
Refactorizando la base de datos, agregando soporte para otro adaptador, las pruebas (como se mencionó anteriormente) se vuelven cada vez más difíciles, ya que escribirás código y, sin darte cuenta, ese nuevo código se adaptará para mantener el singleton .
Esto significa que escribirás código para preservar lo que fue, porque estás trabajando en torno a sus problemas, una mala decisión de diseño.
Piensa en esto, de esta manera:
Usted construye una casa y decide construir un pilar de concreto en el corredor, porque de todos modos colgará los percheros y nunca cambiará eso. Pero Singleton implica que estás escribiendo código OO. El punto es que puedes reutilizar el código. Ahora: ¿de verdad crees que podrás vender tu casa con la misma facilidad si tuviera un perchero inamovible, como lo sería si esa cosa no estuviera allí? ¡por supuesto no!
Y estoy bastante seguro de que solo es útil cuando tienes que llamar a una instancia dos o más veces.
Si es así: use otro patrón, o saque una hoja del libro de Symfony, y haga que la conexión esté disponible para cualquier objeto que lo necesite utilizando un contenedor (el componente de inyección de dependencia vale una búsqueda en Google).
Pruebas:
Todo ha sido explicado anteriormente , pero probar el código singleton es una pesadilla. Aprende a usar la inyección.