¿Es posible acoplar libremente una aplicación a su marco?

Digamos que estoy desarrollando una aplicación web. Mi primera opción es usar PHP con Fat-Free Framework (F3) y el patrón MVC. El año que viene, podría decidir que quiero cambiar a Zend Framework, o tal vez incluso ASP.NET MVC. ¿Tiene sentido intentar diseñar mi aplicación de tal manera que esté acoplada libremente a su marco, o es el marco demasiado integral para hacer que esto sea realista?

La única razón por la que pregunto es porque surgió recientemente en una conversación con un compañero, quien criticó mi idea de pastel en el cielo de acoplar libremente mi aplicación a F3.

Acoplando libremente su aplicación a su marco esencialmente significa que va a escribir un marco proxy. Escribir ese marco proxy es mucho trabajo, y si alguna vez cambias a un nuevo marco, tendrás que hacer mucho trabajo para que el marco proxy sea compatible con el nuevo marco. Por supuesto, los diferentes marcos usan diferentes modismos y patrones, lo que hará que el marco proxy sea muy complejo (si intenta que se ajuste a todo) o muy limitado (si elige el mínimo común denominador). De cualquier manera, tendrás que luchar con ese marco proxy.

¿Tener la capacidad de cambiar los marcos por capricho vale todo este problema? Como dije, no podrá cambiarlo por capricho porque tendrá que ajustar el marco proxy, lo que podría resultar más trabajo que ajustar el código de la aplicación directamente.

No se puede hacer.

Puede diseñar de una manera que sea portátil en los marcos. MVC es MVC, y los principios son más o menos los mismos independientemente del lenguaje o plataforma que se utilice.

Sin embargo, el código real dependerá mucho del marco o del lenguaje. La única forma de abstraerse de eso sería mediante un código basado en un marco intermedio. Entonces puede hacer que la implementación intermedia cambie (¿de F3 a .NET?) Sin cambiar la aplicación. Lo cual es mucho trabajo, supone abstracciones sin fugas y simplemente mueve el problema sin resolverlo: ahora está atado a su marco intermedio.

En una nota más positiva: considere expresar algunas de sus pruebas (estilo BDD) en una plataforma independiente de su implementación. Esos podrían sobrevivir grandes reescrituras.

Una vez vi a Robert C. Martin dar una charla en la que dijo algo como "la primera decisión que tomas es la más difícil de cambiar después".

Entonces, mi consejo es tratar de retrasar esta decisión si aún no está seguro de lo que quiere usar. Identifique las piezas que puede definir ahora y que fácilmente serían independientes de cualquier marco que termine usando.

El bloqueo del marco puede ser un problema grave, pero ayuda a considerar el problema como uno de portabilidad. La portabilidad no es un atributo absoluto, sino relativo a su punto de partida y a dónde posiblemente quiera ir. Por analogía, entonces, el software es portátil solo en la medida en que ya lo haya portado a otros entornos.

La mayor parte del desarrollo de una aplicación dentro de un marco tiende a ser código de pegamento, lo que une los componentes de su marco. Los archivos de configuración pueden abstraer una cierta cantidad de pegamento en algunos sistemas, pero muchos de los detalles deben hacerse en código.

Por otro lado, las reglas y procesos de negocio se pueden abstraer de la aplicación. La parte difícil de la abstracción es cuando las reglas son implementadas directamente por el marco; la seguridad, la accesibilidad y la secuencia de procesos tienden a ser aplicadas por su marco y pueden ser las más difíciles de ver.

Si puede separar la porción de pegamento de su aplicación de la regla de negocios y la porción de proceso de negocios y datos de negocios, entonces podrá hacer que algunas porciones de su solución sean portátiles.