php - framework - yii2 advanced
Migración de proyecto PHP puro al marco Yii (5)
Como ya tienes un código en mvc, será mucho más fácil para ti migrar. Sin embargo, al migrar a Yii, ya que puede generar un controlador y un modelo muy fácilmente usando gii, puede aprovecharlo.
Entonces, primero genere el controlador y el modelo usando gii, luego puede reemplazar su código existente (reemplazando, es decir, sustituir su código con la función específica en el controlador y modelo) por el controlador y el modelo integrados para que la funcionalidad de su sitio todavía funciona. Puede modificar su vista en consecuencia. Pero eso no será mucho trabajo.
Simplemente puede registrar su script para ajax, jquery y css. Esos funcionarán también.
Y sí, Yii es el mejor marco, así que aprovecha los beneficios que puedas.
Gracias, Ujjwal
Casi he completado un proyecto PHP, usando MVC, jQuery y Ajax. Es un proyecto puro de PHP. No utilizo ningún marco en el código correcto. Me gustaría cambiar eso. Al investigar, descubrí que Yii es uno de los mejores frameworks que hay.
¿Es posible de alguna manera migrar un proyecto PHP puro a Yii?
Si es así, ¿cómo hacer esto? ¿Qué pasos debo seguir para reducir la carga de trabajo y disfrutar de los beneficios que presenta el marco Yii?
Soy un novato total de Yii, cualquier idea apreciada.
De hecho, recientemente convertí un sitio web de patrón MVC que había construido desde cero en Yii. Tomó un tiempo para configurar todo, pero honestamente valió la pena. Pude tirar un montón de código porque ya había extensiones Yii haciendo lo que necesitaba. También le sugiero que guarde su base de datos porque puede crear los controladores y modelos usando Gii, lo que le ahorrará mucho tiempo.
En este proyecto, convirtió PHP a yii framework. Es realmente fácil para ti si lo haces siguiendo el paso.
Como ya tienes un código en mvc, será mucho más fácil para ti migrar. Sin embargo, al migrar a Yii, ya que puede generar un controlador y un modelo muy fácilmente usando gii, puede aprovecharlo.
segundo, si su base de datos es precisa, entonces se completa el 50% del trabajo. Cuando crea la operación CRUD usando gii, automáticamente crea el modelo-vista-controlador create.if crea mvc en php, entonces lo beneficia.
tercero, simplemente puede incluir su script para ajax, jquery y css. Esos funcionarán también para crear una carpeta en temas (CSS, JS, AZAX, BOOTSTRAP).
cuatro-Protegido-> vista-> diseño, donde puedes cambiar tu tema ... eso es todo
también ayudas a www.yiiframework.com/doc-2.0/guide-intro-yii.html
si crees que mi respuesta es de ayuda, entonces me calificas ... gracias.
No conozco ninguna solución rápida para esto. Depende de cómo se escribió el código. Usted tiene la base de datos y sus puntos de vista, por lo que no es realmente un proyecto nuevo y completo cuando toma en yii. Yii generará los modelos de base de datos para usted. Ya tiene las vistas del proyecto existente. Escriba el controlador y las acciones y modifique las vistas si es necesario.
prueba estos enlaces ya que se refieren al mismo problema.
¿Cómo se convierte un proyecto oop viejo en Yii?
TL; DR: No lo hagas. Es una idea realmente horrible.
El Rant ...
"Marco" no es una salsa mágica, que se agrega a un proyecto, para hacerlo mejor y más brillante.
Investigando un poco, descubrí que Yii es uno de los mejores frameworks que hay.
Qué investigación tan extraña has hecho ... Me encantaría ver los materiales. Especialmente, ya que lo clasificaría como el tercer peor marco PHP. Solo superado en su horror por CodeIgniter y CakePHP.
Y el motivo es la calidad extremadamente mala del código, que este marco muestra, combinado con las malas prácticas, que perpetúa.
¿Por qué evitar la migración?
De su descripción es obvio, que NO está familiarizado con este marco y no tiene experiencia previa con él.
En la gestión de proyectos existe un tema: gestión de riesgos . Y en este caso, agregar un marco no utilizado anteriormente en las etapas finales del proyecto constituiría una alta probabilidad de un alto riesgo de impacto que también, debido a la sabia del proyecto, no se mitiga por completo .
Significa que hay muchas posibilidades de que algo salga mal. Y cuando lo haga, muy probablemente hundirá el proyecto. O al menos retroceder los datos de lanzamiento por un período de tiempo significativo.
En un mundo perfecto, los marcos se utilizan para simplificar las tareas repetitivas del desarrollo, a costa de algún rendimiento. Esas son las tareas que realiza al inicio del proyecto. No estás al comienzo de un proyecto. Esto significa que no obtendrá ningún beneficio de esta "maniobra".
¿Por qué no Yii?
Como noté antes, también hay razones no solo para evitar agregar marcos a un proyecto existente, sino también razones por las cuales se debe evitar a Yii en particular.
La pesadilla de la herencia
Todo su controlador ampliará la clase CController , que extiende CBaseController , que extiende CComponent
Todos sus "modelos" extenderán ether CActiveRecord o CFormModel , que extiende CModel , que extiende CComponent .
Ambas cadenas contienen variables estáticas y ejecutan métodos estáticos en multitud de otras clases diferentes. La combinación de estos factores hará que la depuración sea extremadamente difícil y tediosa.
Estado global
Hay varias formas de estado global. Uno que las personas en PHP generalmente saben que son variables global . Pero esa no es la única forma. Cada vez que tiene una clase que contiene una variable static , también crea un estado global que puede (y casi siempre) provocará que una instancia aparentemente no relacionada interactúe misteriosamente.
El uso del estado global es una mecánica básica. Verá llamadas estáticas en toda la base de código, y el archivo de configuración de Yii no funcionaría sin estado global.
Y cada vez que llamas a Yii::app() estás accediendo y / o cambiándolo.
Esto hace que la prueba unitaria sea imposible para las aplicaciones Yii. Y la depuración se convierte en ejercicio de usar grep en todo su proyecto.
Acoplamiento apretado
Cuando creas una aplicación en Yii. Se vuelve obligado a eso. No puede ejecutar partes de su aplicación sin iniciar el marco completo. En su mayoría, se debe a la llamada estática, que termina agregando a su código.
Cada vez que agrega una llamada estática en su propio código, ese fragmento de código queda vinculado al nombre de la clase . Eso esencialmente es un acoplamiento estrecho.
Como habrás notado (con suerte), hay otra manera de lograr el mismo efecto: el uso de un new operador. Esa es otra forma de acoplar algún código tuyo a un nombre específico de una clase.
Sin interfaces ... ninguna .. en absoluto
No importa cuán horrible sea la configuración de un proyecto Yii, el archivo de configuración fue un gesto bien intencionado. La forma menos dañina de introducir código externo y reemplazar componentes existentes en una base de código tan desordenada.
Pero desafortunadamente trae al foco los problemas causados por la falta de interfaces y el acoplamiento existente.
Uno de los componentes que los desarrolladores intentarán reemplazar es el CUrlManager . Principalmente debido a la forma en que puede pasar parámetros adicionales.
Una interfaz en OOP especifica el contrato entre dos instancias. Le permite definir las capacidades de una instancia, los métodos que pueden usar otros. Cuando no está allí, en una gran base de código, quedará adivinado, qué métodos son necesarios y cuáles no.
En el caso de los componentes Yii, el problema se agrava aún más debido a llamadas estáticas y herencia profunda. El CUrlManager mencionado CUrlManager extiende CApplicationComponent , que extiende CComponent . También el mismo archivo define las clases CUrlRule y CBaseUrlRule .
Cuando está escribiendo un reemplazo, debe escribir un código, conectarlo a la configuración y luego probarlo ejecutando sus aplicaciones. De esta forma sabrá qué método (o parámetro) a continuación debe agregar.
Básicamente, es el método de desarrollo "save-an-see-what-blows-up" .
¡Eso no es MVC!
Yii no implementa MVC ni ninguno de los patrones de diseño inspirados en MVC. Lo que llama "MVC" podría describirse como un patrón ActiveRecord-Template-Logic .
En lugar de tener una capa de modelo adecuada (sí, debe ser una capa), los creadores de Yii optaron por la recopilación de registros activos y envoltorios de formularios. Esto fuerza a la lógica de la aplicación a ser forzada en los "controladores".
Por otro lado, tiene plantillas glorificadas, en lugar de instancias de vista adecuadas para contener la lógica de presentación. Se mitiga de alguna manera mediante el uso de widgets , pero en su lugar sufren violaciones de SRP , porque los widgets se ven obligados a contener bits de lógica de presentación y realizar una representación parcial. El resto de la lógica de presentación termina nuevamente en los controladores.
Y para empeorar las cosas, los "controladores" también tienen que lidiar con la autorización . Esto generalmente significará que cada vez que cambie el esquema de acceso, tendrá que pasar por cada instancia de CController para verificar si también necesita cambiarse.
No es MVC. Es un desastre con nombres tomados del patrón de diseño de MVC y abofeteado en algunos componentes.
Todas las cosas pequeñas ..
El marco también incluye algunos problemas menores, que no merecen una sección separada:
Definiendo más de una clase por archivo:
Esto se volverá molesto bastante rápido, porque habrá clases que estarán calzadas en los archivos de clase con nombres de archivo completamente no relacionados. Esto significará que la depuración requerirá con bastante frecuencia el uso de la búsqueda.
Slapped en "módulos":
Por lo que parece, los módulos se agregaron al marco después del hecho. Por eso, cuando necesite establecer el módulo predeterminado, tendrá que configurarlo en el parámetro de archivos de configuración, que se llama
''defaultController''.