Entity Framework 6 (codice prima) versioning e auditing di entità

Question

Sto cercando di utilizzare Entity Framework 6.1.1 con SQL Server 2008 R2.

Attualmente sto creando i miei modelli e il database utilizzando la funzionalità EF prima del codice. Il mio caso d'uso di base è quello di creare un diario di tutte le modifiche ad una particolare entità (ID è la colonna chiave) per aiutare gli auditor a tenere traccia di tutte le modifiche apportate e da chi. ad esempio:

|ID|Version|Created Date|Created By|Modified Date|Modified By|Modify Action| ... (rest of entity fields) 
------------------------------------------------------------------------------------------------------- 
| 4| 12 | 12-Mar-14 | tom  | 20-Feb-15 | jack  | Update  | 
| 4| 11 | 12-Mar-14 | tom  | 14-Feb-15 | jill  | Update  | 
| 4| 1  | 12-Mar-14 | tom  | 12-Mar-14 | tom  | Create  | 

Entity Framework supporta questo tipo di schema di database? In tal caso, come posso impostare i miei modelli/soluzione per facilitare questo?

L'altra alternativa che ho è intercettando tutte le chiamate al metodo SaveChanges() sulla DbContext e registrare tutte le modifiche al database in una tabella separata Audit, ma questo potrebbe rendere il recupero di informazioni più impegnativo.

Qualsiasi aiuto sulla creazione di tracce di controllo con SQL Server e EF 6 sarebbe molto apprezzato.

Answer 1

ho usato il secondo approccio si parla, sovraccaricando il metodo DbContext SaveChanges():

public class MyContext : DbContext 
{ 

public int SaveChanges(int userId) 
{ 
    // Get all Added/Deleted/Modified entities (not Unmodified or Detached) 
    foreach (var ent in this.ChangeTracker.Entries().Where(p => p.State == EntityState.Added 
    || p.State == EntityState.Deleted || p.State == EntityState.Modified)) 
    { 

     foreach (AuditLog x in GetAuditRecordsForChange(ent, userId)) 
     { 
      this.AuditLogs.Add(x); 
     } 
    } 
    return base.SaveChanges(); 
    } 
... 

Quindi, se voglio registrare una particolare entità, mi basta chiamare i SaveChanges sovraccarico & passaggio in un UserId :

public void Update(StockCatalogueItem entity, int userId) 
{ 
    _context.SaveChanges(userId); 
} 

ho anche una consuetudine DoNotLog attributo che io uso per decorare le proprietà di entità che non desidera accedere. Senza questo, la registrazione potrebbe generare un'enorme quantità di dati, poiché ogni modifica di entità equivale a una voce db.

[DoNotLog] 
public int CreatedBy { get; set; } 

Il metodo GetAuditRecordsForChange fa il controllo per eventuali DoNotLog proprietà e restituisce un List<AuditLog> che viene salvato nella tabella AuditLogs:

public class AuditLog 
    { 
     public int Id { get; set; } 
     public int CreatedBy { get; set; } 
     public DateTime CreatedOn { get; set; } 
     public AuditEventType EventType { get; set; } 
     public string TableName { get; set; } 
     public int EntityId { get; set; } 
     public string ColumnName { get; set; } 
     public string Controller { get; set; } 
     public string Action { get; set; } 
     public string IPAddress { get; set; } 
     public string OriginalValue { get; set; } 
     public string NewValue { get; set; } 
    } 

Answer 2

si poteva guardare Entity Framework Extended. Ha funzionalità di controllo che ho usato per registrare tutte le modifiche alle entità in XML. Dalla documentazione:

La funzione Registro di verifica acquisisce le modifiche alle entità in qualsiasi momento vengono inviate al database. Il registro di controllo acquisisce solo le entità modificate e solo le proprietà su tali entità che sono state modificate. I valori precedente e successivo sono registrati. AuditLogger.LastAudit è dove vengono conservate queste informazioni e esiste un metodo ToXml() che semplifica la trasformazione di AuditLog in xml per memoria semplice.

È possibile personalizzare AuditLog tramite attributi sulle entità o tramite l'API di configurazione fluente .

UPDATE:

Entity Framework estesa non è più supportato dal 2015. prega di fare riferimento a Entity Framework Plus per questa funzione.

Answer 3

Direi che questo è un buon candidato per il pattern di sourcing di eventi menzionato in un'architettura DDD. Non cambi mai la tabella delle entità ma inserendo sempre.

In questo modo, quando è necessaria una versione specifica, si riproducono tutti gli eventi e li si applicano all'entità dalla versione 0 alla versione che si sta cercando. La scalabilità può essere risolta con istantanee di entità.

Anche il secondo approccio è valido.

Riferimento: http://microservices.io/patterns/data/event-sourcing.html