MVC: ActionLink a otro controlador #MERGE

Hello world,

Desarrollando una de mis primeras paginas con MVC, me he encontrado con el problema de tener que hacer una llamada a un controlador distinto al que tiene mi vista. Como seguramente todos sabéis, para hacer la llamada a la misma vista es tan simple como muestro en el siguiente ejemplo:

@Html.ActionLink("TextoDelLink", "NombreDelAction", "NombreDelControlador", new { id = item.id })

Con esto ya tendríamos creado nuestro link a una nueva vista, siempre y cuando esta esté dentro del mismo controlador. Ahora bien, si lo que necesitamos es llamar a una de vista de otro controlador, seria suficiente con añadir un parámetro mas, el valor de este parámetro seria null, quedando de la siguiente manera:

@Html.ActionLink("TextoDelLink", "NombreDelAction", "NombreDelControlador", new { id = item.id }, null)

Para los no puestos en materia, explicaré cada uno de los parámetros:

  • TextoDelLink: Este es el texto que se muestra en el link.
  • NombreDelAction: Nombre del Action que hemos creado en nuestro controlador.
  • NombreDelControlador: Nombre del la clase del controlador.
  • new { id = item.id }: Lista de parámetros que queremos pasar a la nueva vista.

Con estas líneas tendremos montados nuestros links a otras vistas, tanto del mismo controlador, como de distinto controlador.

Anuncios
MVC: ActionLink a otro controlador #MERGE

Arquitectura DDD y sus capas #MERGE

Hello world,

Con este post pretendo hacer una breve introducción al tipo de arquitectura DDD y explicar la funcionalidad de cada una de sus capas. No entraré en demasiados detalles técnicos, para eso ya existen libros donde profundizar mucho más en este tipo de arquitectura.

¿Qué es DDD (Domain Driven Design)?

Es un tipo de arquitectura de software orientada a dominio (ámbito para el cual estamos desarrollando la aplicación), donde éste es el que se encargará de guiar el desarrollo del software. El objetivo principal es conseguir tener un modelo de dominio rico y que vaya creciendo poco a poco con las nuevas implementaciones.

¿Qué es el Dominio?

El dominio es donde se definen los procesos y las reglas de negocio de nuestra aplicación, es decir, es donde se define la funcionalidad de la aplicación.

Capas de arquitectura DDD.

Antes de nada pongamos un simple diagrama de capas en las que se divide:

ddd1

Un ejemplo de distribución de las capas en el Visual Studio seria el siguiente:

ddd2

Ahora pasaremos a explicar cada una de las capas empezando por la parte superior:

  1. UserInterface: Esta será nuestra capa de presentación. Aquí pondremos nuestro proyecto MVC, ASP, o lo que utilicemos como front-endde nuestra aplicación.
  2. Application: Esta capa es la que nos sirve como nexo de unión de nuestro sistema. Desde ella se controla y manipula el domain. Por ejemplo, dada una persona se requiere almacenar información de un hijo que acaba de nacer. Esta capa se encargará de: llamar a los repositorios del domainpara obtener la información de esa persona, instanciar los servicios del domain y demás componentes necesarios, y por ultimo persistir los cambios en nuestra base de datos.

En esta capa también crearíamos interfaces e implementaciones para servicios, DTOs, etc, en caso de que fuese necesario.

  1. Domain: En domain podemos ver que hay 3 proyectos:
    3.1   Entities: En el cual tendremos nuestras entidades. Es decir, es una clase donde se definen los atributos de la entidad.

    Una entidad tiene una clave que es única y la diferencia de cualquier otra entidad. Por ejemplo, para una clase Persona, podríamos tener los siguientes atributos: Nombre, Apellidos y fecha de nacimiento, en ellos tendríamos la información para la clase Persona.

    Una entidad no sólo se ha de ver como una simple clase de datos, sino que se ha de interpretar como una unidad de comportamiento, en la cual, además de las propiedades antes descritas, debe tener métodos como por ejemplo Edad(), el cual a través de la fecha de nacimiento tiene que ser capaz de calcular la edad. Esto es muy importante, ya que si las entidades las utilizamos simplemente como clases de datos estaremos cayendo en el antipatrón de modelo de datos anémico.

 3.2  Domain: En este proyecto tendremos los métodos que  no se  ciñen a una entidad, sino que lo hacen a varias. Es decir, operaciones que engloben varias entidades.

3.3  Repositories: Aquí expondremos la colección de métodos que  consumiremos desde nuestra capa aplication. En los repositories se va a instanciar las entidades de nuestro dominio, pero no las implementa. Para eso ya tenemos la capa de infrastructure. Por ejemplo New, Update, Delete

  1. Infrastructure: Esta será la capa donde implementaremos repositorios, es decir, donde estarán las querys que ejecutaremos sobre la base de datos.

Espero haber “introducido” en esta arquitectura a gente que nunca haya trabajado con ella, y sobre todo, haber dejado claro la responsabilidad de cada una de las capas.

Arquitectura DDD y sus capas #MERGE

La importancia de “perder” el tiempo en realizar un correcto analisis de base de datos #MERGE

Como os comenté en la presentación, lo primero que haré será publicar las entradas que tengo en el blog que tenía antes. Estas entradas las marcaré con el tag #MERGE.

Este post va orientado a la importancia que tiene en un proyecto el realizar un buen análisis de la estructura de nuestra base de datos, tablas, naming de campos, claves, índices, etc…

La base de datos, hablando en términos de construcción, son los cimientos de la casa, si no tenemos unos buenos cimientos la casa se puede venir abajo, y tampoco vamos a empezar a construir el tejado sin haber hecho previamente los cimientos. Lo más sencillo para todo developer cuando tiene que crear una base de datos es ponerse a “picar” los create table sin haber realizado un profundo análisis de necesidades, lo cual provoca que en un corto plazo de tiempo tengas que cambiar la base de datos, desencadenando una serie de daños colaterales como pueden ser tener que cambiar las consultas, el modelo de datos de tu arquitectura, etc. Está claro, que la base de datos es una de las partes más vivas en la primera parte de desarrollo un proyecto, y que con el tiempo ésta va cambiando porque surgen nuevas necesidades, o cosas que en primer momento pensaste hacer de una cierta manera y cuando te pones a implementarlas te das cuenta que estabas equivocado.

Otro de los puntos clave en el análisis es ver las tablas que realmente necesitamos para nuestra aplicación. Tendemos a querer meter tablas para todo, muchas veces con un simple Id-Descripción que después consumimos desde una sola tabla, pero que cuando queremos obtener los datos tenemos que hace costosas joins en nuestras consultas. Este punto daría para hablar largo y tendido, ya que si somos “políticamente correctos” meteríamos tablas relacionales para todo, pero que después funcionalmente lo único que provocarían sería un desarrollo de la aplicación más lento y costoso. Así que como en todo, los extremos no son buenos, es decir, ni una tabla con 1000 campos donde está  toda la información, ni 1000 tablas con un solo campo.

El punto más dispar que me he encontrado en mi carrera profesional, es el naming de las tablas y de los campos de la base de datos. He encontrado de todo, pero principalmente 2 modelos:

  1. El equipo de desarrollo decide una nomenclatura para los campos.
  2. Se  ponen los nombres de lo que hace referencia cada cosa, siempre siguiendo unos patrones predefinidos.

El punto 1 está muy bien siempre y cuando la rotación en el equipo sea nula (algo muy difícil por no decir imposible), ya que todo el mundo estará familiarizado con dicha nomenclatura, pero desde mi punto de vista puede tener varios inconvenientes: uno seria la rotación de miembros, ya que a la que se incorporaran nuevos componentes, estos tendrían un tiempo de adaptación a esta nomenclatura. Esto podría solucionarse documentando todos y cada uno de los campos y tablas de la base de datos, pero el proyecto tendría que asumir un coste adicional para crear dicha documentación. Pero no todo es malo, esta manera de hacer los naming en la base de datos es buena si un “tercero” accede a nuestra base de datos, ya que este no sabría a qué hace referencia cada campo (tema complicado ya que se “supone” que los servidores donde se alojan las bases de datos de las aplicaciones “deben” proporcionarnos la seguridad de que nadie puede acceder a ellos. Pero esta es la teoría…).

El punto 2 facilita la compresión de nuestra base de datos, ya que de un simple vistazo se puede identificar cada campo. Pero como dije arriba, siempre hay que seguir unos patrones, y un idioma. No puede ser que haya campos que sean en inglés, otros en castellano, etc. Por ejemplo en cada tabla que tengamos un “ID”, éste debe llamarse de la misma forma, no en unos sitios “id” a secas, en otros “Idxxxx”, “xxxxId”, etc. También otra buena práctica es poner en los campos que sean “foreing key” el nombre de la tabla a la que hace referencia. Por ejemplo si tenemos 2 tablas “Country” y “Currency”, el nombre del campo foreing key de la tabla Country debería de ser “CountryId”.

Otro tema al cual no le solemos prestar mucha atención es los tipos de datos de los campos. Aquí hay que tener varias cosas en cuenta:

  1. Si necesitamos 10 caracteres para almacenar un valor, NO ES NECESARIO utilizar un varchar(MAX). El impacto en el rendimiento es significante si sólo hay un campo de ese tipo, pero puede convertirse en un problema cuando TODOS son así.
  2. Campos índices: SQL Server nos proporciona el tipo “autonumérico”, el cual nos facilita el trabajo a los desarrolladores, pero tiene 2 inconvenientes. Uno que ese ID no es único en nuestra base de datos, con lo que no podríamos decir que un Id identifica un objeto concreto, y en cuanto al rendimiento, es más rápido para la inserción, pero más lento para la lectura (en  esto último tengo mis dudas), con lo que la solución para los campos ID es crearlo del tipo uniqueidentifier.
Una vez tengamos nuestra base de datos creada, hay otros aspectos que debemos tener muy en cuenta si queremos ganar rendimiento en nuestra futura aplicación. El principal  es crear índices en nuestras tablas (no voy a entrar en cómo crearlos, ya q no es el objetivo de este post), ya que con esto se puede ganar muchísimo tiempo al realizar las consultas. Esto es algo que a primera vista piensas que no tiene por qué influir en el tiempo que emplea el motor de base de datos en devolvernos la consulta, pero en realidad tener unos buenos índices creados sobre nuestras tablas puede marcar la diferencia de tu aplicación respecto a otras. Y otro de los puntos donde se puede mejorar el rendimiento es en la manea de crear nuestra programación en la base de datos. Por ejemplo, en los “procedimientos almacenados” todos acostumbramos a crearlos como una query  que hace lo que tenga que hacer y listo, pero si en vez de hacerlo así creamos la query como un string y la ejecutamos con un sp_executesql, esto hace que la primera vez que se ejecute el procedimiento almacenado sí que pueda ser más lento, pero las siguientes ejecuciones irá mucho más rápido ya que la query se quedará cacheada en el plan de ejecución del motos de base de datos. Esto último es muy útil cuando por ejemplo tenemos que ejecutar un procedimiento almacenado varias veces.

En conclusión, se podría decir que una de las principales cosas que hacen que un proyecto vaya bien o vaya mal es el tiempo invertido en el análisis y creación de la base de datos. Una estructuración clara y simple de la base de datos hace que nuestra arquitectura de proyecto sea más simple, con lo que será más fácil de desarrollar y sobre todo de mantener en un futuro.

 

La importancia de “perder” el tiempo en realizar un correcto analisis de base de datos #MERGE

Presentación…

Hello world,

Después de un tiempo apartado del mundo de los blogs, me ha vuelto a picar el gusanillo de volver a escribir. Lo primero que haré será traspasar las entradas de mi viejo blog a este.

Una vez hecho esta breve introducción, me voy a presentar. Soy Nacho Fanjul, Senior developer en tecnología .NET en el departamento de proyectos de Pasiona, llevo en este mundo de la programación casi 10 años y como os podéis imaginar me las he encontrado de todos los colores… No voy a entrar a repasar mi trayectoria profesional, para eso podéis visitar mi “LinkedIn”, sí que resumiré lo que llevo haciendo los últimos tiempos.

Me he especializado en desarrollo de aplicaciones web, desarrollando principalmente con MVC, aunque también me ha tocado “pelearme” con webForms. En cuanto a la parte de “BackEnd”, he ido acumulando experiencia en codeFirst, Entity Framework, arquitecturas DDD, etc…

Últimamente, me estoy introduciendo en el mundillo de azure, donde aún me queda un largo recorrido…

¿Qué encontrareis en este blog?

Esto es simple, iré poniendo las cosillas que me vaya encontrando en el día a día, o simplemente cosas nuevas que vaya aprendiendo.

En fin, no me enrollo más, solo deciros que espero que este blog os resulte útil, y podáis aprender algo y que yo también aprenda algo!

Saludos a tod@s!

 

Presentación…