After migrated EF4 CTP5 to RC1, I notice the ObjectContext is no longer accessible through DbContext. It means I can't access ChangeObjectState method.
class DataContext : DbContext
{
public DataContext()
{
}
public DataContext(DbCompiledModel dbModel)
: base(dbModel)
{
}
public DbSet<MyClass> MyClasses { get; set; }
public void ChangeObjectState<T>(T entity, EntityState entityState)
{
// this is no longer working.. where is ObjectContext?
ObjectContext.ChangeObjectState(entity, entityState);
}
}
Has anyone have any idea how access that method in RC1?
Thanks.
You don't need to access ObjectContext to change object state. Use this:
this.Entry<T>(entity).State = entityState;
Related
myDbContext: DbContext
{
DbSet<Person> {get;set;}
//So many domain
}
So I used Set<T> approch
myDbContext: DbContext
{
pubilc DbSet<T> Set<Person> table()
{
return Set<T>
}
}
But now migration is not generating changes or tables
I'm thinking to use ExceptionLogger or ExceptionFilterAttribute in my Web API 2.x application. My OR/M is Entity Framework 6 and AutoFac as my IoC.
Consider exception attribute below:
public class ApiExceptionFilterAttribute : ExceptionFilterAttribute
{
public IDbContext MyContext { get; set; }
public override void OnException(HttpActionExecutedContext actionExecutedContext)
{
base.OnException(actionExecutedContext);
// some code
MyContext.SaveChanges();
}
}
I think, if my app throws any exception OnException method will be invoke and I need a new instance of DbContext to save the error log, but my AutoFac configuration for DbContext is InstancePerRequest so I think AutoFac will resolve MyContext as a shared DbContext.
Here is my AutoFac configuration for DbContext:
builder.RegisterType<DbContext>()
.As<IDbContext>()
.InstancePerRequest();
How could I make AutoFac to reslove DbContext as a new instance for ApiExceptionFilterAttribute?
Ok, since no one answered my question, I talk a little about how everyone could solve this problem. To solve this problem you can only use ServiceLocator pattern (it's an anti-pattern.). By injecting a life-time-scope object of AutoFac you are able to create different scopes.
public class ApiExceptionFilterAttribute : ExceptionFilterAttribute
{
// public IDbContext MyContext { get; set; }
public readonly ILifetimeScope LifeTimeScpoe{ get; set; }
public override void OnException(HttpActionExecutedContext actionExecutedContext)
{
base.OnException(actionExecutedContext);
// some code
using(var scope = LifeTimeScope.BeginLifeTimeScope("ExceptionLogging"))
{
using(var dbContext = scope.Resolve<>(IDbContext))
{
// do some log logic
dbContext.SaveChanges();
}
}
}
}
I want to implement business logic in DbSet derived classes. I like the idea of not having services and DAL abstractions and think this could be a good way. For this to work I need to inject objects into my DbSet but I don't know how. Here some sample code which does not work, because the EF Framework can't create an object of the DbSet. Maybe someone can point me in the right direction?
public class LongTermBookingDbSet : DbSet<LongTermBooking>
{
DbContext _dbContext { get; set; }
public LongTermBookingDbSet(DbContext dbContext )
{
this._dbContext = _bContext ;
}
public override LongTermBooking Add(LongTermBooking entity)
{
return this.Add(entity, false);
}
public LongTermBooking Add(LongTermBooking entity, bool SendMails)
{
var dbSet = base.Add(entity);
//do something with the _dbContext
return dbSet;
}
}
One of the options is to aggregate real DbSet, not derive it:
public class PersonSet : IDbSet<Person>
{
private readonly DbSet<Person> _dbSet;
public PersonSet(DbSet<Person> dbSet)
{
_dbSet = dbSet;
}
}
public class MyDbContext: DbContext
{
public PersonSet PersonSet {...}
}
Inherits from DbSet<T> with the purposes to add property
Is there a way to inherits from DbSet? I want to add some new properties, like this:
public class PersonSet : DbSet<Person>
{
public int MyProperty { get; set; }
}
But I don't know how to instantiate it in my DbContext
public partial MyContext : DbContext
{
private PersonSet _personSet;
public PersonSet PersonSet
{
get
{
_personSet = Set<Person>(); // Cast Error here
_personSet.MyProperty = 10;
return _personSet;
}
}
}
How can I achieve this?
I have found an answer that works for me. I declare my DbSet properties as my derived interface in my context, e.g.:
IDerivedDbSet<Customer> Customers { get; set; }
IDerivedDbSet<CustomerOrder> CustomerOrders { get; set; }
My implementation includes a private IDbSet which which is assigned in the constructor e.g.:
public class DerivedDbSet<T> : IDerivedDbSet<T> where T : class
{
private readonly IDbSet<T> _dbSet;
public DerivedDbSet(IDbSet<T> dbSet)
{
this._dbSet = dbSet;
}
...
}
My implementation of a derived DbContext interface hides the Set<>() method like so:
new public IDerivedSet<TEntity> Set<TEntity>() where TEntity : class
{
//Instantiate _dbSets if required
if (this._dbSets == null)
{
this._dbSets = new Dictionary<Type, object>();
}
//If already resolved, return stored reference
if (this._dbSets.ContainsKey(typeof (TEntity)))
{
return (IDerivedSet<TEntity>) this._dbSets[typeof (TEntity)];
}
//Otherwise resolve, store reference and return
var resolvedSet = new GlqcSet<TEntity>(base.Set<TEntity>());
this._dbSets.Add(typeof(TEntity), resolvedSet);
return resolvedSet;
}
The derived DbContext returns a newly constructed IDerivedSet or picks it's reference cached in a Dictionary. In the derived DbContext I call a method from the constructor which uses type reflection to go through the DbContexts properties and assigns a value/reference using it's own Set method. See here:
private void AssignDerivedSets()
{
var properties = this.GetType().GetProperties();
var iDerivedSets =
properties.Where(p =>
p.PropertyType.IsInterface &&
p.PropertyType.IsGenericType &&
p.PropertyType.Name.StartsWith("IDerivedSet") &&
p.PropertyType.GetGenericArguments().Count() == 1).ToList();
foreach (var iDerivedSet in iDerivedSets)
{
var entityType = iDerivedSet.PropertyType.GetGenericArguments().FirstOrDefault();
if (entityType != null)
{
var genericSet = this.GetType().GetMethods().FirstOrDefault(m =>
m.IsGenericMethod &&
m.Name.StartsWith("Set") &&
m.GetGenericArguments().Count() == 1);
if (genericSet != null)
{
var setMethod = genericSet.MakeGenericMethod(entityType);
iDerivedSet.SetValue(this, setMethod.Invoke(this, null));
}
}
}
}
Works a treat for me. My context class has navigable set properties of my set type that implements a derived interface inheriting IDbSet. This means I can include query methods on my set type, so that queries are unit testable, instead of using the static extensions from the Queryable class. (The Queryable methods are invoked directly by my own methods).
One solution is to create a class that implements IDbSet and delegates all operations to a real DbSet instance, so you can store state.
public class PersonSet : IDbSet<Person>
{
private readonly DbSet<Person> _dbSet;
public PersonSet(DbSet<Person> dbSet)
{
_dbSet = dbSet;
}
public int MyProperty { get; set; }
#region implementation of IDbSet<Person>
public Person Add(Person entity)
{
return _dbSet.Add(entity);
}
public Person Remove(Person entity)
{
return _dbSet.Remove(entity);
}
/* etc */
#endregion
}
Then in your DbContext, put a getter for your Custom DbSet:
public class MyDbContext: DbContext
{
public DbSet<Person> People { get; set; }
private PersonSet _personSet;
public PersonSet PersonSet
{
get
{
if (_personSet == null)
_personSet = new PersonSet( Set<Person>() );
_personSet.MyProperty = 10;
return _personSet;
}
set
{
_personSet = value;
}
}
}
I solved this using another variable to instantiate the "regular" DbSet.
private DbSet<Person> _persons { get; set; }
public PersonDbSet<Person> Persons { get { return new PersonDbSet(_persons); } }
This way entityframework recognizes the Entity but I can still use my own DbSet class.
I know this is really old and the OP has probably moved on but I was just wondering the same thing myself. EF populates the DbSets inside your MyContext at run time.
I just created MyDbSet<T> that inherits from DbSet<T> and the replaced all references to DbSet<T> with my derived class in MyContext. Running my program failed to instantiate any of the properties.
Next I tried setting the properties to IDbSet<T> since DbSet<T> implements this interface. This DOES work.
Investigating further, the constructors for DbSet are protected and internal (the protected one calls the internal one anyway). So MS have made it pretty hard to roll your own version. You may be able to access the internal constructors through reflection but chances are that EF will not construct your derived class anyway.
I would suggest writing an extension method to plug the functionality into the DbSet object, however you're stuck if you want to store state.
I have added a database repository layer to my MVC application which does the CRUD. Sometimes my controllers need to call multiple db repositories and I do this by calling the db respitories I need. This in turn creates multiple db context objects. One for each repository. Should there be multiple db context objects or should I pass in a single db context to the repository object?
In your controller you should use one dbContext. Because When you try to update your model in db, you may get error. Because of different dbContext.
Check HERE
There should be only one, I highly recommend using Unit of Work pattern:
Here's a quick and simple example:
public interface IUoW : IDisposable
{
MyDbContext DbContext { get; set; }
void SaveChanges();
}
public class UoW : IUoW
{
public MyDbContext DbContext { get; set; }
public UoW()
{
DbContext = new MyDbContext();
}
public void SaveChanges()
{
DbContext.SaveChanges();
}
public void Dispose()
{
DbContext.Dispose();
}
}
You need to instantiate UoW once for each request and pass it to your repository:
public class MyRepository
{
private MyDbContext _context;
public MyRepository(IUoW uow)
{
_context = uow.MyDbContext;
}
// your crud methods
}
Of course it's just a very simple example of it and I've seen people implement this pattern in many different ways.