2010-03-25 13 views
11

Estoy compilando una aplicación actualmente en PHP y estoy tratando de decidir si usar un framework preexistente como codeigniter o construir mi propio framework. La aplicación necesita ser realmente escalable y quiero controlarla por completo, lo que me hace pensar que debo construir la mía, pero al mismo tiempo no quiero reinventar la rueda si no tengo que hacerlo.frameworks php: construya el suyo propio 0 pret.

Cualquier consejo muy apreciado.

Gracias

Respuesta

14

Usando el marco existente.

En primer lugar la creación de un marco de cero representa una gran inversión en tiempo y esfuerzo. El proceso implica mucho ensayo y error, porque estás diseñando algo que debe ser simple y poderoso. Para cada decisión de diseño, tendrá que preguntarse cómo afectará cada proyecto futuro que se construirá en su marco.

Cree que podría tomar cada decisión de diseño y sopesarla con los requisitos como lo haría con cualquier otro proyecto de software, pero lo que pasa es que no conoce sus requisitos. No puede conocerlos, porque se supone que un marco puede hacer casi cualquier cosa (o tener la capacidad de extenderse para hacer casi cualquier cosa) dentro de su dominio. El proyecto futuro a deberá poder hacer x. ¿Puede su marco permitir eso sin convertirlo en código de spaghetti? ¿Y si el proyecto b tiene que hacer y? ¿Qué sucede si el proyecto c necesita hacer z?

¿Has predicho todo?

Ahora la respuesta normal a esto es que si algo no funciona, simplemente lo cambiarás en el futuro. Es un software después de todo. Sin embargo, un marco no es como una simple aplicación. Se supone que tiene una interfaz y, una vez que la expones al software que la usará, no puedes cambiarla. Puedes extenderlo, pero no cambiarlo. Entonces ahora debes pensar en métodos de desaprobación, versiones api y compatibilidad de versiones. Se trata de un nuevo conjunto de problemas para tratar junto con el mantenimiento normal del marco y la escritura de nuevas aplicaciones.

Luego está la documentación.Necesitas una API, tutoriales, código de ejemplo. Una vez que construyes tu propio marco, tienes que lidiar con esto también. Podría ignorarlo, pero le aseguro que eventualmente usted mismo tendrá que averiguar qué hace ese método que escribió hace 6 meses. ¿Qué devuelve? ¿Qué sucede si ocurre un caso especial x? ¿Has escrito todo eso o necesitas volver a pasar por el código? Y ni siquiera mencionaré lo fácil que será para un nuevo miembro del equipo iniciarse en un marco personalizado cuya documentación se encuentre completamente o al menos en su cabeza.

También debe reconocer que, a menos que trabaje con los mejores y más brillantes (y tenga un presupuesto que coincida), nunca tendrá el extenso conjunto de bibliotecas que los frameworks existentes presumen. ¿Puedes analizar, diseñar, codificar, probar y depurar más rápido que una comunidad de código abierto?

Finalmente, debe preguntarse si es lo suficientemente hábil para escribir un marco. ¿Has buceado en el código de un framework OO PHP5 moderno para descubrir qué lo hace funcionar? Y lo más importante, ¿sabe usted por qué hace las cosas de esa manera en particular? Tenga en cuenta que cualquier error que cometa en su diseño puede explotar en su cara dentro de unos meses y puede terminar pagándolo una y otra vez.

Para resumir, le aconsejo que vaya con un marco existente; sin embargo, eso no significa que tengas que elegir uno y te guste. Tómese el tiempo que de lo contrario habría dedicado al desarrollo de un nuevo marco y dedíquelo a aprender uno existente. Luego puede ampliarlo para que se ajuste a sus necesidades. También recuerde que podría haber cosas que no podrá hacer. Pero te aseguro que también habría cosas que no podrías hacer con tu propio marco, así que no importa demasiado. Un marco impone algunas limitaciones. Es el precio que paga por poder desarrollar aplicaciones más rápido.

0

La respuesta corta es Symfony2 IHMO.

Las razones son:

  • no reinventar la rueda
  • una buena rueda es mejor que el suyo (los demás son los responsables de la rueda profesionales, ya mucho tiempo)
  • un marco OSS puede expandirse o modificarse, incluso solo inspeccionarse
  • primero o más tarde no tendrá tiempo para mantener su propia rueda
  • ¡varios ojos y manos lo hacen mejor que 2!

¡Por supuesto, los puntos anteriores son válidos para un conjunto muy pequeño de marcos hechos profesionalmente! Mi favorito es symfony2, pero hay una serie de buenas alternativas.

4

Haga una lista de requisitos para su marco (ORM, PHP 5.3, PDO, etc.). A continuación, itere sobre los marcos existentes y acórtelos para encontrar los que coincidan con sus requisitos. Luego, observe la base de código, la documentación, la comunidad, la actividad del proyecto: ¿le parece algo con lo que le gustaría trabajar? También sea realista acerca del tiempo necesario para implementar todos sus requisitos por usted mismo: ¿quiere enfocarse en la creación de una aplicación o un marco?

1

La decisión es muy simple. Si quiere aprender y tener el control total, vaya por su cuenta
Si solo desea ganar dinero rápido, vaya a uno preparado.

2

Si bien he construido mi propio framework CMS en el pasado, y usé frameworks php generales personalizados (internos), encontraría un framework activo que se adapte a su estilo de desarrollo y lo use.

A menos que su producto/aplicación principal sea el marco. Pero no parece de esa manera.

Sus inquietudes sobre el control y la escalabilidad se deben aplicar al host de frameworks que existen, brindándole una breve lista de opciones que se ajustan a sus requisitos.

Ciertamente, no es una cuestión de 'interno' vrs 'público', entonces una vez que haya hecho esa llamada simplemente elija cualquier marco anterior.

Para responder a la pregunta detrás de la pregunta, para un marco que le da control total y debe poder escalar razonablemente bien (no estoy seguro de cómo necesita el marco para escalar), Sugeriría Zend Marco. Puedes usar partes individuales, reescribir lo que quieras y es mucho más que una simple implementación de MVC.

Actualización: Un ejemplo rápido de personalización con Zend. Si no desea usar su pila MVC, pero necesita algo para enrutar las solicitudes, puede usar la biblioteca de enrutadores de Zend. Si te gusta la pila MVC, pero odias la forma en que funciona el enrutador, puedes implementar la interfaz y escribir tu propio enrutador.

Esto se aplica fuera de la pila MVC también. Zend tiene un montón de bibliotecas para correo, fuentes RSS, almacenamiento en caché, auth, db, etc. Usa lo que quieras e ignora el resto. Extienda lo que quiera, la mayor parte del marco está en niveles con interfaces/clases abstractas/generalizadas en las que puede basarse si la funcionalidad estándar no se ajusta a sus necesidades.

1

Yo trabajo en una empresa que inicialmente escribió su propio marco, construido por un tipo que trabajó aquí. Solo se usó en un proyecto. La razón de esto es que pronto nos dimos cuenta de que, aunque era inteligente y muy buena, no había documentación para ello. Entonces, si empleamos a otro desarrollador o un tipo independiente, tendrían que aprenderlo.

Funcionamos con CakePHP por un tiempo, que es popular, pero parece un desastre. Finalmente nos decidimos por KohanaPHP. Fácil de extender, una buena documentación (probablemente no existe con algunos otros, aunque), bien con formato de código (es decir, si no se puede encontrar documentación se puede trabajar rápidamente que hay de nuevo). La forma en que está escrito el marco hace que sea bastante fácil para un desarrollador recoger y seguir lo que está sucediendo. Mientras que siempre tuvimos problemas para hacer esto con CakePHP.

Creo que el único argumento para rodar su propio marco es que puede desear algunas cosas altamente personalizadas. Pero Kohana es tan fácil de extender, que puedes simplemente tirarlo allí. No tiene que usar sus bibliotecas empaquetadas si realmente no desea.

Dicho esto, algunos proyectos no me molestan con un framework en absoluto, solo algún tipo de solución de enrutamiento, como GluePHP. Dado que sería excesivo usar un marco de pila completo.

0

Si solo estuvieras tratando de practicar, te sugiero que escribas el tuyo. De lo contrario, sin embargo, definitivamente vaya con el uso de uno existente. Symfony ftw.

4

Estoy construyendo el mío y estoy muy contento de haberlo aprendido, lo cual es importante para mí. También ME ENCANTA tener el control total de mi código. Sin embargo, viene con muchos aspectos negativos, el más grande es que soy el único que sabe cómo usarlo. Además, se dedica mucho tiempo de desarrollo a mejorar mi marco en lugar de entregar productos a mis clientes. Pero no puedo hacer suficiente hincapié en que realmente, realmente disfruto construirlo y usarlo.

Si quiere aprender (MUCHO) construya el suyo. Si solo quiere terminar el trabajo, use uno existente. (Antes de comenzar el mío casi me fui con CodeIgniter)

Cuestiones relacionadas