c# - que - modelo de dominio online

Entidades VS Modelos de dominio VS Ver modelos

Question

Hay cientos de preguntas similares sobre este tema. Pero todavía estoy confundido y me gustaría obtener expertos para asesorar sobre esto.

Estamos desarrollando una aplicación que utiliza ASP.NET MVC 4 y EF5 y la nuestra es el primer enfoque de DB.

Tenemos la capa de datos en un proyecto separado que es una biblioteca de clases y contiene todas las entidades definidas en él. Y luego Business Layer se definió con todos los repositorios y modelos de dominio (es el término correcto que se utilizará). Y luego viene la capa de presentación.

En este momento no hemos definido ningún modelo de vista, estamos usando los mismos modelos de dominio de BL que los modelos de vista. En este enfoque, un mapeo puede ser suficiente.

ENTITY <=> MODELO DE DOMINIO

Pero para mí no parece un buen diseño. Prefiero tener modelos de vista definidos en mi capa de presentación y usar modelos de dominio para comunicarme entre la capa de presentación y la capa de negocios. Y en BL, convierta objetos de dominio a entidades de datos y comuníquese con DAL. Usando este enfoque, tengo que usar el mapeo dos veces.

Ver modelo <=> MODELO DE DOMINIO <=> ENTIDAD

¿Mi modelo de dominio es realmente necesario? ¿No puedo usar mi entidad para comunicarme con la capa de Presentación? ¿Hay algún impacto si estoy haciendo referencia a entidades en mi capa de presentación? Si hay qué tipo de impactos?

Answer 1

Creo que solo tienes problemas para definir qué es cada capa y qué papel desempeña en tu solución.

Nivel de datos

Su nivel de datos es simplemente su base de datos / lista de SharePoint / archivo .csv / hoja de Excel ... tiene la idea, es simplemente donde se almacenan sus datos, y puede estar en cualquier formato. Así que recuerda que el nivel de datos no es más que solo datos.

// ----------------------------
//    Data tier
//        - MySQL
//        - MS SQL
//        - SharePoint list
//        - Excel
//        - CSV
//        - NoSQL
// ----------------------------

Capa de acceso a datos

Esta capa abstrae su origen de datos y proporciona una API en la que el resto de su aplicación puede interactuar con la fuente de datos.

Tenga en cuenta que nuestra fuente de datos es una base de datos MS SQL y que estamos utilizando Entity Framework para acceder a los datos. Lo que intentará abstraer, es la base de datos y Entity Framework, y tiene un Data Repository para cada Entity .

Ejemplo...

Tenemos una tabla de Customers en una base de datos MS SQL. Cada cliente en la tabla de clientes es una Entity , y se representa como tal en su código C #.

Al utilizar el patrón de repositorio, podemos abstraer la implementación del código de acceso a datos, de modo que en el futuro, si nuestra fuente de datos cambia, el resto de nuestra aplicación no se verá afectado. A continuación, necesitaríamos un CustomersRepository en nuestra Data Access Layer , que incluiría métodos como Add , Remove y FindById . Para abstraer cualquier código de acceso a datos. El siguiente ejemplo es cómo lo lograrías.

public interface IEntity
{
    int Id { get; set; }
}

public class Customer : IEntity
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime RegistrationDate { get; set; }
}

public interface IRepository<TEntity> where TEntity : class, IEntity
{
    TEntity FindById(int id);

    void Add(TEntity entity);

    void Remove(TEntity entity);
}

public class CustomerRepository : IRepository<Customer>
{
    public Customer FindById(int id)
    {
        // find the customer using their id
        return null;
    }

    public void Add(Customer customer)
    {
        // add the specified customer to the db
    }

    public void Remove(Customer customer)
    {
        // remove the specified customer from the db
    }
}

La capa de acceso a los datos se encuentra entre la capa de datos y la lógica de negocios.

// ----------------------------
//    Business logic
// ----------------------------

// ----------------------------
//    Data access layer
//        - Repository 
//        - Domain models / Business models / Entities
// ----------------------------

// ----------------------------
//    Data tier
//        - MySQL
//        - MS SQL
//        - SharePoint list
//        - Excel
//        - CSV
//        - NoSQL
// ----------------------------

Capa empresarial

La capa de negocios se basa en la capa de acceso a los datos y no se ocupa de ninguna cuestión de acceso a los datos, sino estrictamente de la lógica empresarial. Si uno de los requisitos del negocio era evitar que se realizaran pedidos desde fuera del Reino Unido, entonces la capa de lógica de negocios manejaría esto.

Nivel de presentación

El nivel de presentación simplemente presenta sus datos, pero si no tiene cuidado con los datos que presenta y los datos que permite que se publiquen, se enfrentará a muchos dolores de cabeza, por lo que es Es importante usar modelos de vista, ya que los modelos de vista son una preocupación de nivel de presentación, el nivel de presentación no necesita saber nada sobre los modelos de su dominio, solo necesita conocer los modelos de vista.

Entonces, ¿qué son los Modelos de Vista? Son simplemente modelos de datos que están diseñados para cada vista, por ejemplo, un formulario de registro incluiría un RegistrationViewModel , exponiendo estas propiedades típicas.

public class RegistrationViewModel
{
    public string Email { get; set; }
    public string Password { get; set; }
    public string ConfirmPassword { get; set; }
}

El nivel de presentación también maneja la validación de entrada, por lo que validar si una dirección de correo electrónico tiene el formato correcto o si las contraseñas ingresadas coinciden es una preocupación de nivel de presentación, no una preocupación comercial, y puede manejarse usando Data Annotations .

public class RegistrationViewModel
{
    [Required]
    [DataType(DataType.EmailAddress)]
    public string Email { get; set; }

    [Required]
    [DataType(DataType.Password)]
    [Compare("ConfirmPassword")
    public string Password { get; set; }

    [Required]
    [DataType(DataType.Password)]
    public string ConfirmPassword { get; set; }
}

La razón por la que es importante usar View Models es porque los Business Models pertenecen a la capa de negocios e incluyen datos que deben permanecer privados. Por ejemplo, si expone el Modelo de Dominio en una respuesta JSON, expondría los datos completos de los usuarios, su nombre y su dirección, ya que no es selectivo sobre lo que se está exponiendo y lo que no, sino usando lo que sea parece estar funcionando.

También debo señalar que existe una diferencia entre domain models y los entity models . Ya hay una respuesta que entra en muchos más detalles here

Interés transversal

Voy a mantener este breve:

• Gestión de excepciones
• Mapeo de Modelos de Vista a Modelos de Dominio.
  • AutoMapper

Answer 2

El principal beneficio de la introducción de clases adicionales es la separación de las preocupaciones:

• Capa de presentación: muestra información y entrada de datos, incluyendo cualquier preprocesamiento y posprocesamiento para lograr esto, por ejemplo, formateo.
• Dominio / Negocio / Aplicación lógica: aquí el trabajo real está hecho
• Capa de persistencia: almacenar y recuperar datos

Esto se puede lograr con solo dos clases de modelo para ViewModels y Entidades de dominio. En lugar de modelar la lógica de dominio con clases de modelo separadas que son similares a las entidades persistentes, impleméntela en clases de servicio que consumen las entidades de dominio. Las entidades de dominio deberían tener como máximo lógica que trate sus propias propiedades (por ejemplo, para mantener los valores combinados de dos propiedades en un estado válido). Si más de una entidad de dominio se ve afectada por un caso de uso, modele este uso en una clase de servicio. Si pones la lógica para administrar la relación entre las entidades directamente en las clases de entidad, el código se vuelve imposible de mantener muy rápidamente (créeme, lo intenté).

No recomiendo usar las entidades persistentes como ViewModels, porque esto mezclaría problemas de visualización (por ejemplo, [DisplayName] ) con problemas de persistencia (por ejemplo, [ForeignKey] ).

Answer 3

No soy un experto, pero compartiré mis 50 centavos sobre el tema.

Ver modelo

Me gustaría compartir su preocupación acerca de ignorar el Modelo de Vista.

Al usar el modelo de vista, puedes:

1. Seleccione solo los datos que necesita del modelo de dominio
2. Formatee los datos que necesita de la manera correcta para la presentación (por ejemplo, formato de precio decimal (100.00) a cadena (€ 100.00))
3. Puede usar DataAnnotation en su modelo de vista.

Entonces, también lo considero un mal diseño, pero otros pueden tener una opinión diferente.

Recuerde, la capa de negocios no sabe nada sobre el modelo de vista, por lo que debe asignarlo en el controlador.

Entidades vs modelo de dominio

Comenzaría de manera simple, usando un POCO como modelo de dominio que puede persistir con un ORM o un NoRM. Para la mayoría del software desarrollado en el mundo, no dañará mucho su sistema y también es simple.

En el futuro, si comienza a utilizar servicios web por alguna razón, es posible que deba considerar el uso de DTO (objetos de transferencia de datos) para llamadas remotas. Cuando existe, lo que puede hacer es tener otra capa, responsable de mapear su modelo de dominio al DTO deseado. Esta capa se usaría solo en la llamada remota (servicio web), manteniendo el modelo de vista para la presentación.