c# - studio - crear base de datos entity framework

Modelo de entidad vs modelo vs vista (5)

Acabo de pasar algo de tiempo leyendo sobre estos términos (no los uso mucho ya que no tenemos aplicaciones MVC y suelo decir "modelo"), pero tengo la sensación de que esto significa cosas diferentes según el contexto. :

Entidad

Esto es bastante simple, es una fila en la base de datos:

2) En relación con una base de datos, una entidad es una sola persona, lugar o cosa sobre la cual se pueden almacenar los datos.

Modelo

A menudo leo, esto es básicamente una combinación de entidades para representar un conjunto completo de datos, digamos que una lista de direcciones-modelo de un cliente combinaría las entidades cliente, dirección y probablemente individuales.

Viewmodel

Un término en los patrones MVVM o MVC, que es un modelo, que representa exactamente los datos que puede ver en la vista. El modelo de vista se encuentra en el nivel de la aplicación y tiene atributos para la validación, fe ASP.NET MVC Model vs ViewModel

Desde mi punto de vista, estos términos parecen un tanto redundantes: obviamente, el Viewmodel tiene su uso, de lo contrario la vista tendría que hacer todo el trabajo para mostrar lo correcto. La entidad es solo la representación, como sabemos por EF, pero si combina estas dos, ¿dónde está el modelo?

Cosas como validación, seguridad, etc. tienen que hacerse en ViewModel. ¿Usarías el modelo cuando tienes cientos de tablas pequeñas para poner otra abstracción entre las entidades y el modelo de vista? ¿O son en términos de entidades MVC y MVVM y los modelos generalmente lo mismo?

Como de costumbre, gracias y un buen fin de semana

Matthias

Diferentes personas definen Entity, Model y ViewModel de diferentes maneras. Sin embargo, estos términos a veces pueden diferir de su significado real, en función del contexto.

Entidad

Una entidad es la representación tabular de su clase / objeto de dominio en la base de datos y tiene una identidad. De hecho, una entidad representa una sola instancia de su objeto de dominio guardado en la base de datos como un registro. Tiene algunos atributos que representamos como columnas en nuestras tablas.

Por ejemplo, para representar a un cliente como una entidad, debe tener algunos atributos como CustomerId, CustomerName, Address y muchos más, según el contexto. En consecuencia, estos atributos forman las columnas de nuestra tabla de clientes. Y, por lo tanto, cada dato de cliente que guarde en la tabla, representa una entidad de cliente.

Modelo

La gente a menudo confunde a la entidad con el modelo. Sin embargo, estos dos son bastante diferentes. Un modelo típicamente representa un objeto del mundo real que está relacionado con el problema o el espacio del dominio. Mientras programamos, creamos clases para representarlos. Estas clases, conocidas como modelos, tienen algunas propiedades y métodos (que definen su comportamiento) en un espacio de dominio particular. Por ejemplo, en cualquier problema orientado al cliente, podemos tener una clase de cliente que tenga algunas propiedades y métodos.

En algunos marcos ORM (Object Relational Mapper), un modelo está estrechamente vinculado a una entidad. Esto significa que cada propiedad escalar se correlaciona con un atributo de entidad. Sin embargo, si está familiarizado con Entity Framework, debe saber que no todas las propiedades de su clase de dominio se asignan a una columna de entidad. Y esa es una forma en que una entidad es diferente de un modelo.

ViewModel

El término ViewModel se origina del patrón de diseño de MVVM. En el patrón de diseño de MVVM, es el modelo de vista que contiene toda la lógica para manejar las solicitudes / eventos generados por la vista. Podemos decir que un modelo de vista en el patrón MVVM es como un controlador en el patrón MVC.

Sin embargo, hay un lado más. Una vista tiene la responsabilidad de presentar los datos normalmente procedentes de un objeto. Sin embargo, hay instancias cuando los datos provienen de dos objetos diferentes. En tales escenarios, creamos una clase de modelo que consta de todas las propiedades requeridas por la vista. Las diferentes instancias de modelo de dominio luego inicializan este objeto. No es un modelo de dominio sino un modelo de vista porque lo usa una vista específica. Además, no representa un objeto del mundo real.

Diferentes personas entienden estos términos de forma un poco diferente, pero así es como lo entiendo:

Entidad: objeto que tiene una identidad (ID), generalmente proviene de una base de datos. Clase bastante simple.

Modelo: cualquier objeto comercial, este es un término un poco amplio. Puede ser una entidad, alguna clase personalizada que haya creado en su proyecto, etc. Es prácticamente todo lo que no es una vista ni un controlador / modelo de vista.

ViewModel: una especie de mediador entre un modelo y la vista. Modula la comunicación entre el modelo y la vista, por ejemplo aplica validación, combina más modelos en un objeto más grande, etc., a los efectos de la interacción con la vista específica. ViewModel también es responsable del manejo de eventos (por ejemplo, clics de botones del mouse), por lo que expone los comandos a la vista a la que se vincula (WPF).

El término "Modelo" es ambiguo. Todos son modelos.

Modelo de entidad

Una clase que se parece mucho a la estructura en la persistencia. Un MemberEntity es un modelo que representa una fila miembro en la tabla Members en una base de datos. No está estrictamente vinculado a una base de datos, sino a una entidad de cierta persistencia. Normalmente tiene una propiedad de "ID" como "int MemberID".

ViewModel

Una clase que se parece mucho a la estructura en una Vista / IU. Un MemberViewModel es un modelo que representa un miembro que se mostrará en una vista de miembros / UI en la interfaz de una aplicación. No estrictamente relacionado con el patrón MV *.

darse cuenta

... que los dos modelos anteriores representan la comunicación en los límites de la aplicación. Es decir, el límite frontal (punto de entrada) que recibe la comunicación (eventos del usuario y comunicación a través del protocolo) para iniciar las reglas comerciales; Y el límite posterior que toma los comandos de las reglas comerciales para abrir la comunicación con otros sistemas (como bases de datos u otros puntos finales).

Modelo de dominio

Una clase que representa parte del dominio del problema. MemberModel es responsable de su creación y validación. Debido a que los servicios aceptan y devuelven modelos, los modelos son responsables de su propia lógica comercial que valida su correcta construcción y uso. EG: Un MemberModel debería romperse si intentas usarlo sin un UserName.

Servicios de dominio

Los Servicios de dominio toman Modelos de entidad y los transforman en Modelos de dominio para que dichos servicios puedan funcionar con los modelos. Si una Entidad entra desde el límite posterior y no puede serializar o mapear en un Modelo de Dominio, hay una bandera roja que indica que los datos son malos .

Los Servicios de dominio toman Modelos de dominio y los asignan a Entidades para enviarlos al límite posterior. Si el límite posterior (DB / SDK?) No acepta el modelo, el DB / SDK necesita ser reparado.

Nota: Las entidades se ajustan a los modelos porque la persistencia es un detalle. El dominio es el rey de un sistema, no el hardware o la estructura de tabla de la persistencia. El dominio nunca está mal.

Los Front-Boundaries toman ViewModels y los transforman en Modelos de Dominio para que puedan pasar al Dominio. Si un ViewModel no puede serializar o mapear en un Domain-Model, hay una bandera roja que indica que la vista / json / xml es incorrecta.

Los servicios de dominio devuelven modelos de dominio al límite frontal, que luego se asignan a ViewModels para comunicar el frente. Si View / UI no acepta el modelo, la vista debe ser reparada.

Nota: ViewModels se ajusta a los modelos porque los consumidores son un detalle. El dominio es el rey de un sistema, no las UI o Sub-Apps que los consumen. El dominio nunca está mal.

Un modelo de vista NUNCA sabe acerca de una entidad porque una UI / consumidor nunca sabe que la persistencia existe.

Core Business-Logic no debería saber sobre ViewModels o Entities. Core Business-Logic solo funciona con modelos de dominio. Es por eso que existen controladores y servicios frontend cerca de ellos; Para asignar modelos de dominio <=> ViewModels. Esa es también la razón por la que existen SDK''s y Backend-Services cerca de ellos; Para asignar entidades de DomainModels <=>.

Cuando se construye un sistema, el dominio y la lógica de negocios se construyen primero (esperemos que TDD). A continuación, los adaptadores se colocan en el anverso y el reverso de la lógica comercial que determina el mecanismo de entrega (frontend) y las dependencias (servicio / persistencia) (servidor). Pero esos frontends y backends podrían ser arrancados, y la lógica empresarial central todavía existe.

Versión más corta (TLDR;):

Entidad: registro de la base de datos.

Modelo de dominio: lógica de negocio específica del modelo ("Objeto de valor" de Google) para representar un objeto en el Problema del dominio.

ViewModel: Página (o sección) de una Vista.

La definición de estos términos es bastante ambigua. Encontrarás diferentes definiciones en diferentes lugares.

Entidad : una entidad representa una instancia única de su objeto de dominio guardado en la base de datos como un registro. Tiene algunos atributos que representamos como columnas en nuestras tablas.

Modelo : un modelo típicamente representa un objeto del mundo real que está relacionado con el problema o el espacio del dominio. En la programación, creamos clases para representar objetos. Estas clases, conocidas como modelos, tienen algunas propiedades y métodos (que definen el comportamiento de los objetos).

ViewModel : el término ViewModel se origina del patrón de diseño MVVM (Model View ViewModel). Hay instancias en las que los datos que debe representar la vista provienen de dos objetos diferentes. En tales escenarios, creamos una clase de modelo que consta de todas las propiedades requeridas por la vista. No es un modelo de dominio sino un ViewModel porque lo usa una vista específica. Además, no representa un objeto del mundo real.

Para obtener más detalles, visite: Entity vs Model vs ViewModel vs DataModel

Mi entendimiento es que el Modelo es una noción central aquí, refleja la comprensión del problema que se está resolviendo. Las entidades determinan cómo se almacenarán los objetos del modelo en la base de datos. Los Viewmodels determinan qué parte del modelo se mostrará al usuario final.