GIT

En nuestro proyecto usamos como mínimo la versión 2013 del Visual Studio, ya que esta nos permite usar el versionamiento de versiones el GIT.

Su uso es muy sencillo:

- Seleccionamos “Open from source Control”

- Ahora para añadir un repositorio, presionamos la opción “Add”

- Agregamos la URL y donde va ubicarse en nuestra computadora

- El resultado final debe ser un repositorio añadido.

Conclusión

Decidimos usar GIT por los siguiente motivos:

• -       Git se distribuye
• -       Git es más rápido
• -       Git tiene un tamaño más pequeño por repositorio
• -       Generar ramas y trabajar con los equipos es más fácil

HATEOAS

Para la implementación de un servicio sea RESTful necesitábamos que también cumpla con la característica HATEOAS (Hypermedia as the Engine of Application State). Esta restricción permite al cliente interactuar de manera dinámica a través del hipermedia proporcionado por el servidor de aplicaciones. En consecuencia, el cliente REST puede navegar sin necesidad de tener la necesidad de conocer como interactuar con cualquier aplicación o servidor.

Para esto, solicitamos ayuda al profesor del curso, quien nos brindo la siguiente solución.

- Crear una tabla en la base de datos con las URLs correcpondientes de nuestras entidades o recursos.

- Al momento de obtener los datos, de la base de datos. Utilizar un Store Procedure que añada el hipermedia a cada objeto que se tenga en el llamado.

El resultado final de un JSON con hipermedia sería el siguiente:

{ 

"codigo" : "u201418583",

"nombre" : "Flavio",

"href" : "www.blog.com/UPC.svc/alumnos/u201418583"

}

En este caso se obtiene la información de un objeto específico.

En conclusión...

Para implementar el hipermedia barajamos varias alternativas, algunas eran APIs externos y otras implementaciones en el código menos óptimas. Al final optamos por la solución proporcionada por el profesor, ya que nos pareció que no se involucraba con el código y si en algún momento se quisiera cambiar la URL de acceso a los recursos se trabajaría directamente con la base de datos.

CRUD

Según los requerimientos del software, este debe ser RESTful. Por ende tuvimos que ser cuidados que operaciones del CRUD implementaremos en nuestro sistema. 

Por este motivo nuestro grupo se reunió para sincerar que operaciones implementará el sistema y así obtener las operaciones finitas  que usaremos.

El resultado fue el siguiente:

Foto capturada del resultado final de la reunión

En conclusión...

- No usamos la operación DELETE, ya que una de nuestras reglas de negocio es tener un histórico de las operaciones en la base de datos y salvaguardar los registrospara esto algunas tablas tienes el atributo estado y otras el atributo versión.

Modelando la base de datos

Para realizar el modelo de la base de datos, primero de identifico a todas la entidades que involucraba el sistema. Hasta allí no hubo inconvenientes, ya que el problema fue al momento de relacionarlas. Una de estas relaciones que se nos complico más fue el vinculo entre un PCR (documento creado por el proveedor IBM) y la cotización.

Al principio consideramos a la cotización como un atributo más del PCR, pero después de un largo análisis, nos percatamos que tal decisión iba a traernos complicaciones. Esto porque la cotización también tiene un detalle que especifica el costo detallado del servicio. 

Al final, tomamos la decisión la independizar cada una en su propia tabla, en la cual el PRC tiene como llave foránea a la cotización. La relación entre estas es de 1 a 1, ya que una versión de PCR únicamente puede tener una cotización. De tal manera cada versión tendrá su propia cotización y hay un histórico de cotizaciones por PRC.

Modelado final entre las tablas PCR y cotización

En conclusión...

La relación entre estas entidades pudo haber sido de maneras distintas. Lo cual no significa que una este incorrecta y la otra bien. El modelado de la base de datos se tiene que adecuar a las reglas del negocio y a las necesidades del cliente. Tal como sucede en nuestro caso.