Come impostare campi privati ​​su un modello di dominio nel repository

Question

Attualmente sto lavorando con un codebase che utilizza il modello di dominio anemico e sto cercando di spostare più logica nei modelli di dominio in uno spostamento verso un modello di dominio e un dominio Driven Design, ma sono alle prese con il seguente problema.

Ho un modello di dominio chiamato lavoro che assomiglia a questo,

public class Job 
{ 
    private DateTime _someOtherDate; 
    private DateTime _lastUpdated; 

    // this may be called from many different services 
    public void SetLastUpdated() 
    { 
    _lastUpdated = DateTime.UtcNow; 
    } 
} 

Ad un certo punto nel tempo, durante l'elaborazione di un lavoro che desidera impostare data dell'ultimo aggiornamento del lavoro a quel punto specifico nel tempo. Per fare questo ho creato un setter pubblico per questo come puoi vedere sopra.

Un problema sorge quando sto ritirando il lavoro dal database nel mio repository, poiché ora non ho un setter pubblico per questo campo perché l'ho limitato a SetLastUpdated().

Qualcuno può consigliare come consentire a questa proprietà di essere impostata nell'implementazione del repository quando si recupera il lavoro, ma non dal servizio in cui è limitato alla chiamata SetLastUpdated().

Aggiornamento 1) Ho aggiornato la domanda poiché la data di inizio era un cattivo esempio.

Update 2) Dalle risposte fornite, l'unico modo che posso vedere questo viene fatto è non usando automapper nel repository, l'aggiunta di un costruttore sulla classe di lavoro per l'impostazione _lastUpdated, e l'utilizzo di questo quando la costruzione del lavoro da restituire nel metodo di recupero del lavoro del repository.

Answer 1

Un approccio comune è quello di utilizzare i costruttori di questo

public class Job 
{ 
    private DateTime _startDate; 

    public void Job() 
    { 
    _startDate = DateTime.UtcNow; 
    } 

    public void Job(DateTime dt) 
    { 
    // check DateTime kind, this could be source of a bug 
    if(dt.Kind != DateTimeKind.Utc) throw new ... 
    _startDate = dt; 
    } 
} 

Bisogna esporre questo metodo/proprietà un modo o nell'altro. Se il repository può impostarlo, è possibile impostarlo da altre posizioni. Se si cerca di essere intelligenti su questo (si potrebbe, ad esempio, utilizzando le interfacce), si rischierebbe di sovrastimare.

Answer 2

Uno dei motivi principali per cui si sta facendo DDD è sfruttare la mutabilità gestita che può essere fornita dall'incapsulamento. Questo è sempre che inizia con il costruttore.

In generale, questo è il tipo di lavoro un ORM è specificamente progettato per eseguire, ma può anche trarre vantaggio da eventuali DTOs esistenti che sarebbero stati mappati sull'oggetto dominio utilizzando il memento pattern:

public Job() { 
    _lastUpdated = DateTime.UtcNow; 
    // ... 
} 

public Job(JobData data) { 
    _lastUpdated = data.LastUpdated; 
    //... 
} 

re: AutoMapper - è da un po 'di tempo da quando l'ho usato, ma dovrebbe essere possible for you to instruct it to access fields using reflection in the configuration.

Answer 3

Come vedo, ci sono varie opzioni.

Opzione 1

Supponendo che il repository ha due metodi:

public IEnumerable<Job> ReadAll() { ... } 
public int CreateJob(Job job) { ... } 

si può dare la classe Job due costruttori, uno che prende uno DateTime e che non.

public class Job 
{ 
    public Job(DateTime startDate) 
    { 
     this.StartDate = startDate; 
    } 

    public Job() : this(DateTime.UtcNow) 
    { 

    } 

    public DateTime StartDate { get; private set; } 
} 

Ciò non toglie che il servizio di chiamare il costruttore "sbagliato", ma almeno comunica la possibilità di chiamare senza il startDate al chiamante.

Opzione 2

Lavora con due differenti Job classi.

Il repository potrebbe apparire come questo, invece:

public IEnumerable<Job> ReadAll() { ... } 
public int CreateJob(NewJob newJob) { ... } 

E la classe NewJob potrebbe apparire come:

public class NewJob 
{ 
    public NewJob() 
    { 
     this.StartDate = DateTime.UtcNow; 
    } 

    public DateTime StartDate { get; private set; } 
} 

Questo comunica l'intenzione migliore, perché il metodo del repository Create accetta solo un'istanza di NewJob quindi l'utente del modello sarà costretto a creare uno NewJob anziché uno Job.

Opzione 3

Ignora la StartDate nel metodo di repostory Create e sempre impostarlo su DateTime.UtcNow all'interno del metodo. O addirittura arrivare a creare un trigger Insert nel database che lo imposta.