Desde anémico de dominio a dominio controlado por

Question

Yo estaba tratando de encontrar un claro y sencillo ejemplo de lo que un anémico dominio realmente significa.Hay un montón de teoría, y también muchas de las preguntas contestadas.Aun así, no podía obtener una imagen clara acerca de en qué medida "anémico de dominio", que significa que realmente pasa.Por lo tanto, creo que sería más sencillo ver un maniquí ejemplo práctico de un anémico dominio de diseño y de preguntar ¿cómo podría ser esto evolucionó a un dominio controlado por uno...

Así, supongamos que tenemos los datos de entidad de tipo TaskData:

public class TaskData
{
    public Guid InternalId { get; set; }

    public string Title { get; set; }

    public string Details { get; set; }

    public TaskState ExplicitState { get; set; }

    public IEnumerable<TaskData> InnerTasks { get; set; }

}

Y existe la necesidad de una propiedad adicional llamado "ActualState", la cual es calculada estado:si la Tarea tiene interior sub-tareas, el valor depende estrictamente de los niños, de lo contrario, el "ActualState"es igual a "ExplicitState"

Si escribo esta lógica en un separado servicio clase (yo los llamo "motores") tenemos:

internal class TaskStateCalculator
{
    public TaskState GetState(TaskData taskData)
    {
        if (taskData.InnerTasks.Any())
        {
            if (taskData.InnerTasks.All(x => this.GetState(x) == TaskState.Done))
            {
                return TaskState.Done;
            }
            if (taskData.InnerTasks.Any(x => this.GetState(x) == TaskState.InProgress))
            {
                return TaskState.InProgress;
            }

            return TaskState.Default;
        }

        return taskData.ExplicitState;
    }       
}

El primera pregunta es:

¿El código anterior reflejan un anémico dominio de diseño, incluso si la TaskStateCalculator servicio/motor es parte de mi Capa de Dominio?Si sí, con el fin de evitarlo, tendremos que mover la lógica dentro de la TaskData clase (y cambiar el nombre de TaskData a Tarea).Estoy en lo cierto?

El segunda pregunta es (en realidad una cadena de ellos):

Lo que si tenemos una situación más difícil?Digamos que hay es la necesidad de una propiedad llamada ComputeSomething dentro de Tarea entidad, y la lógica de esta propiedad necesita para acceder a la totalidad de la Tarea repositorio.En este caso, el Tarea clase tendría una dependencia en TaskRepository.Sería aceptar?¿Cómo EF crear una instancia de dicha clase?¿Cuál es la alternativa?

Answer 1

Yo estaba tratando de encontrar un claro y sencillo ejemplo de lo que un anémico dominio realmente significa

De hecho, es muy fácil ir de un anémico modelo de dominio a un rico.

1. Conjunto de todos los bienes de incubadoras para private y, a continuación, agregar métodos si desea cambiar el estado de un modelo.
2. Evaluar todos los La ley de Demeter violaciones y agregar métodos adecuados.

Finalmente, usted tendrá un modelo correcto.

En tu caso yo lo encapsular la lógica dentro de TaskData como su TaskStateCalculator violar la Ley de Demeter

public class TaskData
{
    public Guid InternalId { get; private set; }

    public string Title { get; private set; }

    public string Details { get; private set; }

    public TaskState ExplicitState { get; private set; }

    public IEnumerable<TaskData> InnerTasks { get; private set; }

    public TaskState GetState()
    {
        if (!InnerTasks.Any())
            return ExplicitState;

        if (InnerTasks.All(x => this.GetState(x) == TaskState.Done))
        {
            return TaskState.Done;
        }

        if (InnerTasks.Any(x => this.GetState(x) == TaskState.InProgress))
        {
            return TaskState.InProgress;
        }

        return TaskState.Default;
    }       
}

otra cosa es que probablemente no lo haría exponer InnerTasks colección en todo el mundo exterior (sólo la tienen como un campo de miembro).Pero es difícil decir que yo no sé cómo se utiliza la clase en otros escenarios.

Por qué privada incubadoras

Cada vez que tienes que cambiar más de una propiedad es a menudo mejor para describir el comportamiento de un método, ya que es imposible olvidar a cambiar todas las propiedades requeridas.Un método también describe mejor lo que están tratando de hacer que el cambio de un conjunto de propiedades.

Incluso si usted acaba de cambiar una sola propiedad, la propiedad se puede establecer la clase en un estado no válido como el cambio puede no ser compatible con el resto de la información de la clase.No olvides que la encapsulación es uno de los principios básicos de la programación orientada a objetos