Utilizzando IQueryable <TEntity> invece DbSet <TEntity> problema

Question

mi sono imbattuto al problema successivo ... devo contesto di database:

// For support unit testing... 
public interface IDbContext : IDisposable 
{ 
    IQueryable<Hardware> Hardwares { get; } 
    IQueryable<ProviderHardware> ProviderHardwares { get; } 
} 

// Real DbContext (EF 4.0, Code First) 
public class PrimaryDbContext : DbContext, IDbContext 
{ 
    public DbSet<Hardware> Hardwares { get; set; } 
    public DbSet<ProviderHardware> ProviderHardwares { get; set; } 

    IQueryable<Hardware> IDbContext.Hardwares 
    { get { return Hardwares; } } 
    IQueryable<ProviderHardware> IDbContext.ProviderHardwares 
    { get { return ProviderHardwares; } } 
    ... 
} 

e cerco ottenere tutte le parti metalliche, che esiste pretende molto nella tabella ProviderHardwares:

var hardwaresRemoved = db.Hardwares.Where(i => (i.IsAvailable == true) && 
    (db.ProviderHardwares.Count(j => j.Article == i.Article) == 0)).ToList(); 

Se uso PrimaryDbContext rigorosamente come "PrimaryDbContext db = new PrimaryDbContext();" tutto funziona bene Ma se lo uso implicitamente "IDbContext db = new PrimaryDbContext();" che ottengo un'eccezione:

Impossibile creare un valore costante di tipo 'ConfiguratorMvcApplication.DomainModels.ProviderHardware'. Solo i tipi primitivi ('come Int32, String e Guid') sono supportati in questo contesto in .

Riassumere, non è possibile sostituire un DbSet su un IQueryable. E come posso usare il test delle unità in questo caso? Spero che qualcuno abbia ancora risolto questo problema ... Grazie in anticipo molto!

Answer 1

suggerisco è meglio mantenere DbSets e fare test di integrazionecompreso il database.

Perché, sebbene passare un test di unità con una simulazione di DB potrebbe essere un po 'utile, sarà meglio testare con un database reale (ma non è un test di unità).

In ClassInitialize, cancellare il database e/o creare i dati iniziali per il test.

Se si crea un file App.config con una stringa di connessione, è possibile avere un database di test separato e, se si utilizza prima il codice EF, lo si ottiene gratuitamente.

Cordiali saluti.

Answer 2

Alla fine ho avuto due proprietà per ogni DbSet: una di tipo IQueryable e una di tipo DbSet. La proprietà IQueryable è definito nell'interfaccia, e trasmette le chiamate verso l'attuazione concreta (proprietà di tipo DbSet), come segue:

// Exists in the interface 
public IQueryable<AccountContact> AccountContacts 
{ 
    get 
    { 
     return DbAccountContacts; 
    } 
    set 
    { 
     DbAccountContacts = (DbSet<AccountContact>)value; 
    } 
} 

// Exists only in the implementation 
public DbSet<AccountContact> DbAccountContacts { get; set; } 

Avere questa configurazione, sono stato in grado di ottenere beffardo per funzionare correttamente e potrebbe unità testare il codice.

Questo è decisamente troppo tardi per l'OP, ma forse questo aiuta qualcuno che sta lottando con la stessa domanda, come ho fatto io.