Come progettare la classe thread-safe quando si separa la business logic da POCOs

Question

Come progettare la classe thread-safe quando si separa la business logic da POCOs

Naviga le tue risposte

#1 da (1 voti)

0

Mi piace separare la logica di business dai POCO ai controllori.

Se un oggetto deve essere thread-safe, dove inserisco il codice di blocco? Nello stesso POCO? O in un controller?

Potrebbe avere senso perché i tipi di valore non possono essere bloccati?

I.e., il controller:

namespace Project1.Controllers
{
    public class LogManagerController
    {
        private object _lock = new object();

        public LogManager Fill(TimeSpan interval, DateTime? lastLog)
        {
            return new LogManager {Interval = interval, LastLog = lastLog};
        }

        public void Update(LogManager logManager, DateTime lastLog)
        {
            lock (_lock)
            {
                logManager.LastLog = lastLog;
            }
        }

        public DateTime? Get(LogManager logManager)
        {
            lock (_lock)
            {
                return logManager.LastLog;
            }
        }
    }
}

Il modello:

namespace Project2.Models
{
    public class LogManager
    {
        public TimeSpan Interval { get; set; }
        public DateTime? LastLog { get; set; }
    }
}

c# multithreading poco controller

posta Hoppe 04.10.2018 - 22:40

fonte

1 risposta

Leggi altre domande sui tag c# multithreading poco controller

Esiste una best practice per i ruoli con un'applicazione web MVC di Spring su un sistema host? Progetta una gerarchia ad albero delle classi di proprietà

score 1 · Answer 1

L'unica ragione per cui riesco a vedere dove potresti incorrere nella sicurezza dei thread qui è dovuta alla necessità di mantenere sincronizzati Interval e LastLog . In tal caso, evita del tutto il problema rendendo immutabile quella classe:

namespace Project2.Models
{
    public class LogManager
    {
        public LogManager(TimeSpan interval, DateTime? lastLog)
            => (Interval, LastLog) = (interval, lastLog);

        public TimeSpan Interval { get; }
        public DateTime? LastLog { get; }
    }
}

Quindi, quando i valori cambiano, crea una nuova istanza di LogManager , invece di mutare un valore esistente.

Ma detto questo, non c'è niente di simile al tuo codice che suggerisce questo è il caso. Aggiorna LastLog ma lascia Interval da solo. Quindi non è chiaro il motivo per cui ritieni che questa classe potrebbe non essere già infallibile.