Costruire CMS dai componenti

Devi valutare ogni componente e pensare se ha davvero senso:

• Devi pensare a quanto è probabile che dovrai sostituire una libreria con un'altra. Nel caso di un ORM, potresti voler sostituire un RDBMS con un altro, ma un ORM di solito fornisce già quell'astrazione, quindi è improbabile che tu voglia anche cambiare il tuo ORM.
• Devi pensare a quanto sarebbe universale l'API del tuo proxy. Non ha senso creare una complessa API proxy se non si è in grado di mantenere tale API nel caso si cambi un componente. Ad esempio, probabilmente non sarebbe possibile mantenere la stessa API se si intende passare da SQL a DBMS non SQL. D'altra parte, potrebbe essere ragionevole abbandonare una libreria crittografica diversa perché molti di essi hanno funzioni e API simili.
• Lo sforzo di scrivere un nuovo livello proxy sarebbe effettivamente inferiore rispetto all'aggiornamento della base di codice principale? Se una libreria depreca una funzione o due ogni qualche anno che sono utilizzate solo in alcuni punti, sarebbe difficile giustificare la scrittura di un proxy per l'intera libreria nel caso in cui un piccolo numero di tali funzioni cambi, il che richiederebbe solo uno sforzo minimo per aggiornare in ogni caso in qualsiasi modo.

Come esempi generali:

• Probabilmente non verificherei un ORM perché un ORM è già un'astrazione, aggiungerebbe una notevole complessità per trasformare le strutture dati restituite da un ORM in qualcosa di generico, e probabilmente non avrò un motivo convincente per interruttore.
• Probabilmente avrei proxy qualcosa come un'API di archiviazione degli oggetti cloud, perché è probabile che in futuro io possa voler utilizzare un altro provider di archiviazione e spesso hanno un'API simile o identica.

Forse più importante della loro API è la tua API.

Se:

• La tua API è ben definita, in particolare per quanto riguarda le API pubbliche e non
• La tua API fa un buon lavoro di incapsulare le librerie all'interno (cioè evita di esporre i costrutti specifici di implementazione / libreria a consumatori esterni)
• La tua API è ben coperta da una suite di test automatizzata

Quindi, anche se è necessario eseguire un re-plumbing significativo dell'applicazione per sostituire una libreria o eseguire l'aggiornamento a una versione con un'API incompatibile, è comunque possibile essere certi che il sistema funzioni ancora come in precedenza. prospettiva esterna e che non stai trasmettendo questi problemi ai tuoi utenti.

Perché non hai un aspetto (per esempio) nell'interfaccia Symfony DBAL o Templating? Se vuoi fornire componenti con un'implementazione esterna sottostante diversa, definirai i componenti dell'interfaccia e fornirai un paio di adattatori per quelle altre librerie.

Per mantenerlo compatibile all'indietro semplicemente non cambiare l'interfaccia . Se qualcosa, ad esempio, cambia Doctrine, puoi cambiare gli adattatori .