.NET objeto de jerarquía - Para evento o no al evento

Question

Su trabajo consiste en diseñar una biblioteca de clases plan de proyecto que apoya el seguimiento de las tareas (similar a cómo funciona MS Project). Esta biblioteca de clases tiene un objeto Task (entre otros).

El objeto Task tiene una EstimatedHours (Double), StartDate (DateTime), y las propiedades EndDate (DateTime), entre otros. Un objeto puede tener una Task Task padres, y varios niños Task objetos. Las propiedades EstimatedHours, StartDate y EndDate de un Task que tiene hijos (es uno de los padres) dependen de las propiedades de sus hijos inmediatos. Task del StartDate padre es el primer StartDate de sus hijos. Task del EndDate padre es el último EndDate de sus hijos. Task del EstimatedHours los padres es la suma de EstimatedHours de sus hijos. Por lo tanto, no es válido para cambiar estas propiedades en un Task que tiene hijos.

¿Cómo manejaría el caso de uso donde los EstimatedHours, StartDate, o EndDate se cambian en una tarea que tiene un padre? (propiedades de los padres son un reflejo de sus hijos, por lo que cualquier cambio en los niños pueden requerir propiedades de los padres para ser ajustadas para reflejar los cambios apropiadamente)

Una opción es tener un evento para cada uno cuando cambia la propiedad. Un Task padre escucharía para estos eventos en objetos de sus hijos inmediatos Task, y hacer los cambios apropiados en sus propias propiedades cuando ocurrieron esos eventos. Es esta una buena aproximación, o hay una mejor manera? ¿Cómo sería lo hace?

Esto es una idea básica de lo que es un objeto Task podría ser:

Public Class Task

  Private mChildren As List(Of Task)

  Private mEndDate As DateTime = DateTime.MinVlue
  Public Property EndDate() As DateTime
    Get
      Return mEndDate 
    End Get
    Set(ByVal value As DateTime)
      mEndDate = value
      'What to do here?
    End Set
  End Property

  Private mEstimatedHours As Double = 0.0
  Public Property EstimatedHours() As Double 
    Get
      Return mEstimatedHours 
    End Get
    Set(ByVal value As Double)
      mEstimatedHours = value
      'What to do here?
    End Set
  End Property

  Private mStartDate As DateTime = DateTime.MinVlue
  Public Property StartDate() As DateTime
    Get
      Return mStartDate 
    End Get
    Set(ByVal value As DateTime)
      mStartDate = value
      'What to do here?
    End Set
  End Property

End Class

Answer 1

El enfoque correcto para resolver este problema será utilizar Diseño Observador Patrón. explicación detallada de la aplicación de patrón Observer está más allá del alcance de esta discusión. Pero aquí hay algunas excelentes conexiones de patrón de observador. Un enlace es aquí y otro es aquí .

http://www.dofactory.com/Patterns/PatternObserver.aspx

http://en.wikipedia.org/wiki/Observer_pattern

Espero que esto ayude.

Ruchit S.

Answer 2

No estoy seguro de que esta es la forma en que realmente lo haría, pero aquí hay una opción diferente: en lugar de permitir que una tarea de tener hijos, utilizar dos objetos, una tarea y un taskset que implementan una interfaz ITask. Una tarea tendría su propio StartDate, EndDate y EstimatedHours, sino una taskset sería calcular dinámicamente los valores de sus tareas secundarias. Utilizar un servicio para agregar y quitar los niños a un ITask. Para añadir, sería convertir una tarea en una taskset cuando se añade el primer hijo. Para la eliminación, sería convertir el taskset de nuevo en una tarea cuando a continuación se elimina el último hijo y establecer las propiedades de los valores en los que el último niño.

Answer 3

Tenga en cuenta que cuando un evento en una cadena de eventos se produce una excepción, los siguientes eventos no van a ser invocado. Así que si hay otros eventos registrados a los datos que puede sea posible su evento no será llamado.

Si es crucial para su aplicación que la tarea de base nunca está fuera de contacto con sus hijos, entonces no use eventos.

Answer 4

Me primero construir el modelo de objetos de manera que se calcula sobre la marcha de los valores. Voy a darle C # como soy más comftorble con él (También estoy usando campos en lugar de propiedades para mantener el pequeño de la muestra):

public class Task
{

    public List<Task> Children=new List<Task>();
    public Task Parent;   
    private int _duration;

    public int Duration
    {

       get
       {
          if (Children.Count>0)
          { 
              return SumChildrenDuration();
          }

          return _duration;
       }

       set 
       {
          if (children.Count>0)
              throw new Exception("Can only add to leaves");
          _duration=value;
       }
    }
}

Una vez que tenga esto en su lugar ahora tiene todo el código que necesita para hacer funcionar su sistema. Puede encontrarse con que el sistema realiza lo suficientemente bien y dejarlo así. De lo contrario se puede añadir en una funcionalidad adicional para almacenar en caché el resultado y luego restablecer la caché cuando un objeto cambia. Haga lo que haga, asegúrese de que el perfil de cerca como usted quiere asegurarse de que su almacenamiento en caché y la espiración no es más caro que acaba de calcular sobre la marcha.

Answer 5

No consideraría esto una parte de la responsabilidad del modelo, sino más bien del controlador en la parte superior de la misma.

Adición de eventos o patrones de observación a un modelo añade complejidad en otras áreas, tales como la serialización, que tendrá que evitar.

Hacer que la responsabilidad de la clase que hace que la modificación, no el propio modelo. Recuerde:. La responsabilidad del modelo es contener la información, no implica las reglas de negocio

Answer 6

Yo digo a mis desarrolladores de ASP.NET, "Eventos supervisan. Métodos de hacer el trabajo."
  Los eventos deben ser poco más que IFblocks llamar a los métodos. Sin try / capturas etc.
  Métodos hacen todo el acceso a los datos / manipulación / validación / cálculo etc.
  Esto crea "reutilizable de código" modos de pensar en mis desarrolladores también.

Mantiene las cosas separadas.
También es paralelo a los conceptos MVC bastante bien.

Los controladores reaccionan a eventos. Ellos supervisan. Se llaman a los métodos del modelo.
Modelos de hacer el trabajo.

No es un paralelismo perfecto.
Es cierto, es simplista, pero lo hace para bastante buenas directrices.