.Net oggetto gerarchia - Per corsa o di non evento

Question

Il vostro compito è quello di progettare una libreria di classi piano di progetto che supporta il monitoraggio delle attività (simile a come funziona MS Project). Questa libreria di classi ha un oggetto Task (tra gli altri).

L'oggetto ha una Task EstimatedHours (Double), StartDate (DateTime), e EndDate proprietà (DateTime), tra gli altri. Un oggetto può avere uno Task Task genitore, e diversi bambini Task oggetti. Le proprietà EstimatedHours, StartDate, e EndDate di un Task che ha figli (è un genitore) dipendono le proprietà dei suoi figli immediati. Task del StartDate genitore è il più antico StartDate dei suoi figli. Task del EndDate genitore è l'ultima EndDate dei suoi figli. Task del EstimatedHours genitore è la somma di EstimatedHours dei suoi figli. Pertanto, non è valido per modificare queste proprietà su un Task, che ha dei figli.

Come si gestisce il caso d'uso in cui le EstimatedHours, DataInizio o EndDate vengono modificati in un compito che ha un genitore? (proprietà del genitore sono un riflesso dei suoi figli, in modo che eventuali modifiche i bambini possono richiedere le proprietà del genitore da regolare per riflettere i cambiamenti in modo appropriato)

Una possibilità è quella di avere un evento per quando ogni modifiche alle proprietà. Un Task genitore avrebbe ascoltato per questi eventi sugli oggetti dei suoi immediati bambini Task, e apportare le modifiche appropriate alle sue proprietà quando tali eventi si sono verificati. È questo un buon approccio, o c'è un modo migliore? Come direbbe fare?

Ecco un'idea di base di ciò che un oggetto Task potrebbe apparire come:

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

L'approccio giusto per risolvere questo problema sarà quello di utilizzare Observer Design Pattern. spiegazione dettagliata di attuazione pattern Observer esula dall'ambito di questa discussione. Ma qui ci sono alcuni ottimi collegamenti per il pattern Observer. Un collegamento è qui e un altro è qui .

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

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

Spero che questo aiuti.

Ruchit S.

Answer 2

Non sono sicuro che questo è come mi piacerebbe davvero farlo, ma ecco una diversa opzione: Invece di permettere una task di avere figli, utilizzare due oggetti, un compito e un taskset che implementano un'interfaccia ITask. Un compito sarebbe proprio StartDate, EndDate e EstimatedHours, ma un taskset sarebbe dinamicamente calcolare quei valori dalle sue attività figlio. Utilizzare un servizio per aggiungere e rimuovere i bambini ad un ITask. Per aggiungere, sarebbe convertire un compito in un taskset quando si aggiunge il primo bambino. Per l'eliminazione, sarebbe convertire il taskset di nuovo in una Task quando l'allora ultimo figlio viene rimosso e impostare le proprietà dai valori su l'ultimo figlio.

Answer 3

Tieni presente che quando un evento in una catena di eventi genera un'eccezione, i seguenti eventi non stanno andando ad essere invocate. Quindi, se ci sono altri eventi registrati per i dati che possono essere possibile non sarà chiamato il vostro evento.

Se è fondamentale per la vostra applicazione che il compito di base è sempre in contatto con i suoi figli, quindi non utilizzare gli eventi.

Answer 4

Vorrei prima costruire il modello a oggetti in modo che calcola sulla valori volare. Sto per darvi C # come sono la maggior parte comftorble con esso (Sono anche utilizzando i campi invece di oggetti da conservare il campione piccolo):

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 volta che hai questo nel posto che ora hanno tutto il codice è necessario eseguire il sistema. Si potrebbe scoprire che il sistema esegue abbastanza bene e lasciarlo così. In caso contrario, è possibile aggiungere a funzionalità aggiuntive per memorizzare nella cache il risultato e quindi reimpostare la cache quando un oggetto cambia. Qualunque cosa facciate essere sicuri al profilo da vicino come si vuole assicurarsi che il caching e di scadenza non è più costoso quindi solo calcolare al volo.

Answer 5

Non vorrei considerare questo una parte della responsabilità del modello, ma piuttosto del controller su di esso.

L'aggiunta di eventi o modelli osservatore a un modello aggiunge complessità in altre aree, come ad esempio la serializzazione, che si vuole evitare.

Lo rendono la responsabilità della classe che fa la modifica, non è il modello stesso. Ricorda:. La responsabilità del modello è quello di contenere le informazioni, non implica le regole di business

Answer 6

Io dico ai miei sviluppatori ASP.NET, "Eventi supervisionare. Metodi fare il lavoro."
  Eventi dovrebbero essere poco più di IFblocks chiamare i metodi. No try / catture ecc
  Metodi fanno tutti i dati di accesso / manipolazione / validazione / calcolo ecc
  Questo crea "riutilizzabile-code" mentalità nei miei sviluppatori pure.

Si mantiene le cose separate.
E in parallelo anche i concetti MVC abbastanza bene.

Controllori reagiscono agli eventi. Alla loro vigilanza. Lo chiamano metodi del modello.
I modelli fanno il lavoro.

Non è un perfetto parallelo.
Vero, è semplicistico, ma rende abbastanza per buone linee guida.