asp.net-mvc - route - mvc c# tutorial

Lógica empresarial ASP.NET MVC en modelo de dominio frente a capa de servicio

Question

He estado leyendo acerca de dónde poner la lógica comercial en ASP.NET MVC Project por un tiempo y todavía no puedo aclarar algunas cosas.

1 - Modelos de dominio . ¿Qué son estos realmente? En mi carpeta Modelo, tengo solo un grupo de clases correspondientes a mi base de datos. Estoy usando el código EF primero. Supongo que estos son mis modelos de dominio.

2 - Capa de servicio . Esta respuesta sugiere una capa de servicio y creo que tiene mucho sentido. Yo había decidido ir con este. Sin embargo, el artículo "Modelos de dominio anémico" de Martin Fowler me hizo perder la cabeza.

No estoy muy seguro de cómo puedo agregar lógica a mis modelos de dominio.

He pasado por muchas preguntas relacionadas con la lógica de negocios y cada una de ellas propone 1 o 2. Lo que no entiendo es cómo puedo implementar la primera. Agregar métodos a clases de entidades (modelos de dominio para mí) no tiene ningún sentido. ¿Y por qué el segundo enfoque se considera malo?

Answer 1

En primer lugar, su carpeta Model en su proyecto Asp.Net MVC se debe usar para ViewModels. Estos son los modelos que sus Controladores envían a sus Vistas. Deberían estar altamente optimizados para la Vista, lo que significa solo las propiedades necesarias para la vista, y nada más.

Lo que está tratando, los Modelos de Dominio, son los mismos que los Modelos Comerciales, y pertenecen a su Capa Comercial. La carpeta Modelo en su proyecto Asp.Net MVC son los modelos para su capa de interfaz de usuario.

El segundo enfoque, la lógica empresarial en la capa de servicio (realmente comercial) no se considera malo. Es un muy buen amortiguador entre su capa de datos y su capa de interfaz de usuario (arquitectura de 3 niveles). Su capa de datos maneja la obtención de datos, ya sea de servicios web o de una base de datos, y la capa de negocio / servicio maneja la traducción de esos datos en modelos comerciales / de dominio. También contiene cualquier lógica comercial, como cálculos, etc.

Estos modelos de negocio / dominio son generalmente POCO, pero no tienen que serlo. Así es como a veces configuro mis modelos de negocios:

public class BusinessObject
{
    private DataObject _dataObject;

    public BusinessObject(DataObject dataObject)
    {
        _dataObject = dataObject;
    }

    public int BusinessId
    {
        get {return _dataObject.Id;}
        set {_dataObject.Id = value;}
    }

    public string Name
    {
        get {return _dataObject.Description;}
        set {_dataObject.Description = value;}
    }
}

Answer 2

La lógica de control de flujo de aplicaciones pertenece a un controlador.

La lógica de acceso a datos pertenece a un repositorio.

La lógica de validación pertenece a una capa de servicio.

Una capa de servicio es una capa adicional en una aplicación ASP.NET MVC que media la comunicación entre un controlador y la capa de repositorio.

La capa de servicio contiene lógica de validación comercial.

Por ejemplo, una capa de servicio del producto tiene un método CreateProduct ().

El método CreateProduct () llama al método ValidateProduct () para validar un producto nuevo antes de pasar el producto al depósito del producto.

Fuente: http://www.asp.net/mvc/overview/older-versions-1/models-data/validating-with-a-service-layer-cs

Answer 3

Los modelos de dominio deben poder realizar su trabajo por su cuenta y exponer propiedades y métodos que representen su estado y funciones. Actúan como raíces (raíces agregadas) a una jerarquía de información que los modelos requieren para funcionar. Permanecen ocultos solo disponibles para los servicios.

Los servicios exponen la funcionalidad empresarial / de dominio al mundo exterior (servicios web, UI, etc.) como un conjunto de API siguiendo el patrón de mensaje (solicitudes / respuestas), recuperando modelos de los repositorios que encapsulan la capa de acceso a datos y luego llamando a métodos / negocios funciones en los modelos y finalmente guardarlos en los repositorios.

Algunas veces se siente que los servicios repiten los métodos de los objetos de negocios, pero en el tiempo y la práctica real eso no es lo que realmente sucede.

En un diseño impulsado por un dominio real necesita al menos 3 conjuntos de objetos. Business Objects, repositorios de Business Objects y servicios.

Piense como si su requisito siempre fuera que cada tipo de componente está escrito por diferentes equipos. Un equipo requiere un servicio expuesto sin conocer los detalles y sin que el otro tenga que escribir la lógica en el servicio. El servicio podría ser consumido por cualquiera que lo requiera sin tener que profundizar en el modelo básico.

Answer 4

Prefiero NO tener lógica comercial en los modelos de dominio. Mantengo mis modelos de dominio generalmente como POCO para representar mis tablas DB / esquema.

Mantener la lógica comercial lejos de los modelos de dominio me permitirá reutilizar mi modelo de dominio con otro proyecto también.

Puede considerar una capa intermedia entre sus controladores y su capa de acceso a datos / capa Repositary para manejar esto. Yo llamaría esto como una capa de servicio.

Answer 5

Sé que esto ya ha sido respondido, pero categorizo ​​los modelos en 3 grupos

ViewModels: estas son clases ligeras (a menudo poco) que modelan los datos que necesita una página en su sitio. Estas clases manejan la repetición rutinaria de lo que se muestra al usuario y cambia cuando cambia la información que desea mostrar.

Modelos de dominio: normalmente son clases de lógica empresarial de gran peso. Normalmente modelan las reglas básicas del negocio para lo que estás haciendo. Estas clases son a menudo altamente cohesivas y es donde sucede la mayor parte del trabajo que hace que su sitio sea especial. Dije que estos modelos son normalmente pesados, pero en realidad si todo lo que hace es tomar esos datos del usuario y pegarlos en la base de datos, esta clase va a ser una pequeña clase de mapeo de datos. Muchas veces verá que estas clases están compuestas por modelos de persistencia y modelos de vista de retorno.

PersistenceModels: estos son modelos de su mecanismo de persistencia. Para la mayoría de nosotros esto significa modelar una tabla de base de datos, pero también podría ser un documento complejo de nosql o datos json (o lo que sea) que se devuelve de una solicitud de API. Su responsabilidad es manejar la placa de la caldera mundana de la forma que toman sus datos externos.

Tenga en cuenta también que no siempre necesita tener estos tres tipos de modelos presentes en su proyecto. A veces, su modelo de vista será línea por línea de lo que es su modelo de persistencia. En ese caso, estarías desperdiciando dinero de tus clientes para escribir todo el asunto dos veces y agregar un modelo de dominio para asignar uno al otro. Usted es el desarrollador y su trabajo es saber cuándo crear un transportista de aviones para ir a la tienda a comprar alimentos.