c# - unit - net core ddd

DDD con código EF primero: ¿cómo unirlos?

Question

Estoy aprendiendo desarrollo de DDD por unos días, y me empieza a gustar.

Yo (creo que) entiendo el principio de DDD, donde se centra principalmente en los objetos de negocios, donde tiene agregados, agregados de raíces, repositorios solo para agregados de raíces, etc.

Estoy intentando crear un proyecto simple en el que combino el desarrollo de DDD con el enfoque de Code First.

Mis preguntas son: (Estoy usando asp.net MVC)

1. Los objetos de negocio de DDD serán diferentes a los objetos de Code First? Incluso si es probable que sean iguales, por ejemplo, puedo tener un objeto de negocio de Product que tiene todas las reglas y métodos, y puedo tener un objeto de Código de Product primero (POCO) que solo contendrá las propiedades que necesito guardar en la base de datos .

2. Si la respuesta a la pregunta 1 es "verdadera", ¿cómo notifico al objeto POCO del Product se ha cambiado una propiedad del producto comercial y que tengo que actualizarlo? Estoy usando un "AutoMapper" o algo como esto? Si la respuesta es "no", estoy completamente perdido.

¿Me puede mostrar el ejemplo más simple (CRUD) de cómo puedo poner esos dos juntos?

Gracias

Answer 1

Última pregunta sobre este tema. La lectura de la respuesta de Josh Kodroff confirma mis pensamientos sobre la implementación de un Repositorio en, por ejemplo, Entity Framework DAL.

Asigna el objeto de dominio a un objeto de persistencia EF y deja que EF lo maneje al guardar. Al recuperar, le permite a EF obtener de la base de datos y asignarlo a su objeto de dominio (raíz agregada) y agregarlo a su colección.

¿Es esta la estrategia correcta para la implementación del repositorio?

Answer 2

El curso Pluralsight: Entity Framework en la empresa aborda este escenario exacto de diseño impulsado por dominio incorporado con el código EF primero.

Para el número 1, creo que puedes hacerlo de cualquier manera. Es solo una cuestión de estilo. Para el número 2, el instructor en el video recorre un par de formas para dar cuenta de esto. Una forma es tener una propiedad "Estado" en cada clase que se establece en el lado del cliente al modificar un valor. El DbContext entonces sabe qué cambios persisten.

Answer 3

La respuesta es No. Una de las mejores cosas de los códigos EF primero es que encaja muy bien con DDD, ya que tiene que crear sus objetos comerciales a mano, así que use sus modelos EF para que sean equivalentes a las entidades DDD y objetos de valor. No es necesario agregar una capa adicional de complejidad, no creo que DDD lo recomiende en ninguna parte.

Incluso podría tener sus entidades para implementar una entidad y valorar los objetos para implementar la entrada, además, seguir el resto de los patrones de DDD, es decir, los repositorios para realizar la comunicación real a la base de datos. Más de estas ideas puede encontrar esta muy buena aplicación de ejemplo en .NET, aunque no use el código EF primero, sigue siendo muy valioso: http://code.google.com/p/ndddsample/

Answer 4

Recientemente he hecho un proyecto similar. Estaba siguiendo este tutorial: link Y lo he hecho de esta manera: he creado una solución en blanco, he agregado proyectos: Dominio, Servicio y WebUI.

Simplemente dijo en el dominio que he puesto el modelo (por ejemplo, clases para el código EF primero, métodos, etc.) El servicio se usó para que el dominio se comunique con el mundo (WebUI, MobileUI, otros sitios, etc.) utilizando asp.net webapi WebUi era MVC aplicación (pero el modelo estaba en el dominio por lo que era principalmente VC)

Espero haberte ayudado

Answer 5

Actualización Ya no abogo por el uso de "objetos de dominio" y en su lugar abogo por el uso de un modelo de dominio basado en mensajería. Vea here para un ejemplo.

La respuesta al # 1 es que depende . En cualquier aplicación empresarial, encontrarás 2 categorías principales de cosas en el dominio:

Recta CRUD

No hay necesidad de un objeto de dominio aquí porque el siguiente estado del objeto no depende del estado anterior del objeto. Es todo datos y ningún comportamiento. En este caso, está bien usar la misma clase (es decir, un EF POCO) en todas partes: edición, persistencia, visualización.

Un ejemplo de esto es guardar una dirección de facturación en un pedido:

public class BillingAddress {
  public Guid OrderId;
  public string StreetLine1;
  // etc.
}

Por otro lado, tenemos ...

Máquinas de estado

Debe tener objetos separados para el comportamiento del dominio y la persistencia del estado (y un repositorio para hacer el trabajo). La interfaz pública en el objeto de dominio debería ser casi siempre todos los métodos nulos y no los captadores públicos. Un ejemplo de esto sería el estado del pedido:

public class Order { // this is the domain object  
  private Guid _id;
  private Status _status;

  // note the behavior here - we throw an exception if it''s not a valid state transition
  public void Cancel() {  
    if (_status == Status.Shipped)
      throw new InvalidOperationException("Can''t cancel order after shipping.")
    _status = Status.Cancelled;
  }

  // etc...
}

public class Data.Order { // this is the persistence (EF) class
  public Guid Id;
  public Status Status;
}

public interface IOrderRepository {
  // The implementation of this will:
  // 1. Load the EF class if it exists or new it up with the ID if it doesn''t
  // 2. Map the domain class to the EF class
  // 3. Save the EF class to the DbContext.
  void Save(Order order); 
}

La respuesta al # 2 es que DbContext rastreará automáticamente los cambios a las clases EF.