I was having a look at CTP5 of EntityFramework and the code first fluent interface. It looks very nice, but is there a way to make the DbContext expose only interface types and the in the fluent interface's model binder define a concrete implementation to use?
No, as of CTP5, EF Code First does not support interfaces and this feature is unlikely to be supported in the RTM that is targeted to be released this year.
Related
I am using Entity Framework and would like to use TPH with interfaces. So I have a created an interface, "ICustomer", which maps to "SimpleCustomer" and "DiscountedCustomer" class as shown below. Below is the model builder code. From what I understand we can not use interfaces with Entity Framework, so what's the best way?
modelBuilder.Entity<ICustomer>().ToTable("tblCustomer")
.Map<SimpleCustomer>(x => x.Requires("CustomerType").HasValue("S"))
.Map<DiscountedCustomer>(x => x.Requires("CustomerType").HasValue("D"));
My application uses interfaces all over the UI and would like to have a smooth type casting to Entity Framework. So is what the best way?
Entity Framework does not support TPH with interfaces (sorry for stating the obvious). This may not be the solution you are looking for, but I am still going to put it there because it seems to be the only solution as of 16 April 2015.
In Entity Framework 6, the closest you can get is - Use abstract classes instead of interfaces. This article talks about TPH in EF in great detail.
My suggestion is if you want to use interfaces and maintain the hierarchy and also still want smooth typecasting, consider using automapper with abstract classes. This way your UI will still use Interfaces, but can be mapped to domain model using automapper profiles. Atleast till the interface support arrives. It will not be a quick one if the application is large and has hundreds of domain models, so need to plan it wisely.
If you are creating it from scratch, you can simply use abstract classes from UI layer to DAL without any re-factoring.
I used the EF 5.x DbContext Fluent Generator to generate my POCO classes but my properties are not coded as virtual. Don't you have to have that for tracking to occur? Why wouldn't the template already use virtual for properties?
Because we found that for the majority of users it was better to use snapshot change tracking rather than change tracking proxies. Change tracking proxies have their place in certain situations, but usually they add complexity without any real benefit. For more info see http://blog.oneunicorn.com/2011/11/24/why-are-the-dbcontext-t4-templates-so-different-from-the-ef4-poco-templates/ and http://blog.oneunicorn.com/2011/12/05/should-you-use-entity-framework-change-tracking-proxies/
I'm developping a line of business application using WPF as a presentation layer (of course with MVVM).
I'm using ADO.Net Entity Framework to map the DataBase.
I don't want to use entities directly in code (in the business layer). I want to separate my project into 3 layers:
Presentation layer
Business Layer
Data Access Layer
According to this post I want to implement a full encapsulation of the Entity Framework to provide a separation of concerns and to not be dependant on EF as ORM in the future.
Can you help me by giving me some exemples to encapsulate the EF and how to implement this in code.
Regarding this
I want to implement a Full encapsulation of the Entity Framework. to
provide a separation of concerns and to not be dependant on EF in the
future as ORM
Normally, you will create yourself a lot of problems if you go that route. If you choose EF, you really should make full use of the features, not hiding that behind another abstraction.
EF itself is already an abstraction layer over DB, there is no need to create another abstraction on top of that.
I would take a look at this post wich implements UnitOfWork and Repository patterns to implement what, I understand, you want to achieve.
http://blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx
There is one way of doing it, using POCO. Entity Framework 4.0 comes with the support of POCO (Plain CLR Objects). But POCO has its own complexities, when u have to deal with Relationship and associations. You can refer to the blog by Julie Lerman (a nice article)
http://thedatafarm.com/blog/data-access/agile-entity-framework-4-repository-part-1-model-and-poco-classes/
I am trying to implement a caching pattern which may need to utilise Redis. The problem with this pattern is that I need to disable Configuration.ProxyCreationEnabled and then re-enable it afterwards to avoid any issues across a web farm.
What I would like to do is access the DbContext from the IQueryable so I can do this once instead of everywhere. The easiest way to do this is to pass the DbContext being used into my caching extension, however I came across this post:
Access DataContext behind IQueryable
Is there a way of accessing the DbContext in a similar manner to the link above using EF 4.1 Code Fist (DbSet's, etc)?
I have tried to find this myself but have struggled to find the base class from the referenced DbSet in the IQueryable using reflection.
The solution mentioned in Access DataContext behind IQueryable is a hack and should not be used. It relies on the name of a private member variable in the class implementing IQueryable. This means that the implementing class could change in a future release of EF/.NET Framework and break your code. Since the DbContext is not accessible through the IQueryable interface, you should pass it into your caching extension to avoid making assumptions about the IQueryable implementation. Doing so will also more clearly establish the dependency on the DbContext in your caching interface, instead of burying it in the implementation.
What is the importance of POCO support in Entity Framework?
Maybe its better to ask What is the uses of POCO ?
Actually POCO is similar to POJO (Plain old java objects) in .net world. POCOs are objects tha don't have to follow any particular conventions (implementing any interface ,extending any class,having special attributes or naming convention etc.)
Some of the persistent frameworks force us to use specific interfaces or attirbutes , abstract classes. This is not a problem as long as you are working on a project from scratch and you are choosing which framework to use but if you are working on a legacy system and want to change its data access layer to use a persistent framework , it might have a negative impact.
Realy short:
That you have objects that didn't know anything about the EntityFramework but are bound to it (Bound to the context so that the EntityFramework can take care).