5.2. CRUD de pedidos modelo y controlador (cm_orders)
Vamos a crear el controlador para la gestión de los pedidos desde nuestra WEB que se corresponderá a la tabla cm_order, para ello vamos a generar las clases bases del controlador, modelo y migraciones con un único comando:
$ <strong>docker-compose exec admin-app-lpm php artisan make:model CmOrder --controller --migration --resource</strong>
5.2.1. Definimos la migración para la tabla cm_order para los pedidos
La tabla cm_order la definimos en el diagrama entidad relacionado con los clientes, donde un cliente puede tener varios pedidos.
5.1.1. Definimos la migración para la tabla cm_customer de clientes
La tabla cm_customer la definimos en el diagrama entidad relación con empresas, donde un cliente pertenece a una empresa: 7
AÑADIR IMAGEN DE LA ENTIDAD RELACIÓN CLIENTES / PEDIDOS.
El SQL de la tabla cm_order que vamos a ver a continuación nos sirve de definición de la tabla en la migración:
CREATE TABLE cm_order ( idorder INT NOT NULL AUTO_INCREMENT, idcustomer INT, order VARCHAR(50), ordertype VARCHAR(50), description VARCHAR(500), units DECIMAL(10,3), totalprice DECIMAL(10,3), taxes DECIMAL(10,3), address VARCHAR(500), CONSTRAINT pk_cm_order PRIMARY KEY (idorder), CONSTRAINT un_cm_order_order UNIQUE (order), CONSTRAINT fk_cm_order_idcustomer FOREIGN KEY (idcustomer) REFERENCES cm_customer (idcustomer) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, ) ENGINE=InnoDB COMMENT='Tabla de pedidos.'; GRANT ALL ON TABLE cm_order TO xulescode;
Teniendo en cuenta esta base SQL la definición de la migración para la tabla de pedidos en la aplicación ORDERS APP teniendo en cuenta la clave foránea para los clientes quedará así:
use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; class CreateCmOrdersTable extends Migration { /** * Run the migrations. * * @return void */ public function up() { /** * Tabla de pedidos. * * idorder INT NOT NULL AUTO_INCREMENT, * idcustomer INT, * order VARCHAR(50), * ordertype VARCHAR(50), * description VARCHAR(500), * units DECIMAL(10,3), * totalprice DECIMAL(10,3), * taxes DECIMAL(10,3), * address VARCHAR(500), * CONSTRAINT pk_cm_order PRIMARY KEY (idorder), * CONSTRAINT un_cm_order_order UNIQUE (order), * CONSTRAINT fk_cm_order_idcustomer FOREIGN KEY (idcustomer) * */ Schema::create('cm_order', function (Blueprint $table) { $table->increments('idorder'); $table->unsignedInteger('idcustomer'); $table->foreign('idcustomer')->references('idcustomer')->on('cm_customer'); $table->string('order', 50)->unique(); $table->string('ordertype', 50); $table->string('description', 500); $table->decimal('units', $precision = 10, $scale = 3); $table->decimal('totalprice', $precision = 10, $scale = 3); $table->decimal('taxes', $precision = 10, $scale = 3); $table->string('address', 50); $table->engine = 'InnoDB'; // Specify the table storage engine (MySQL). }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::dropIfExists('cm_orders'); } }
5.1.2. Creamos el modelo para la tabla de pedidos (cm_order)
Creamos el modelo para la tabla cm_customer (clientes), la definición la haremos en CmCustomer dentro de la carpeta de los modelos app/Models, los campos que definimos en la migración los llevamos a la tabla:
PEPIDOS
Aquí no vamos a entrar en detallles ya que la definición la explicamos anteriormente lo que si tenemos que tener en cuenta es que en esta aplicación los clientes nos vienen dados de la aplicación ADMIN-APP para conservar la integridad entre aplicaciones vamos a utilizar los ids que se generén en esta aplicación como ya indicamos en la creación de la migración por eso marcamos la opción incrementing = false; indicando que la creación de la clave primar no es auto incremental.
5.1.3. Detallamos el recurso para clientes (Resource)
Vamos a definir la respuesta de los servicios de nuestra API para clientes, así organizamos estructuralmente la devolución de registros, esto lo hacemos en la clase CmCustomerResource dentro de app/HTTP/Resources
Definición de resources.
5.2.4. Añadimos las rutas para la WEB
Para definir las rutas que utilizaremos en la WEB dentro de la carpeta routes, en el fichero web.php de definición de rutas para la WEB, y completamos con el acceso a todas las rutas CRUD:
RUTA PARA PEDIDOS
5.2.5. Definimos el controlador para los pedidos vía WEB
Para la parte de gestión de pedidos vamos a añadir todos los elementos CRUD, para ello desarrollaremos todos los métodos que generamos por defecto:
ajldjfañljdl