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.
Related
I am using entity framework to build a data driven app. I have a base class which has lots is shared properties such as timestamp,Id,creator etc and I subclass this for all of my actual objects.. Is this a good design? Is there a limit to the amount of entities I can create like this?
It is good design. It would be bad design, of course, if Entity Framework didn't support inheritance as an ORM feature. But it does!
As far as I know, there is no practical limit to the number of entities you can define and use in Entity Framework.
I am new to entity framework and MVC, and trying to understand what constitutes a good design approach for a new application.
There are several ways of using Entity Framework. However, for my project, the best looking option is DB First. I've played around with an EDMX file, and I have got as far as using the DbContext code generator to create my wrapper classes.
I plan on using the repository and unit-of-work patterns, and using ninject for DI.
However, it does not seem "proper", from a SoC point of view, that whilst my respository will hide the implementation of the data store (EF) from my code, the model classes themselves are very much EF flavoured.
It seems that using EDMX-based approaches to EF blur the separation of concerns. Only POCO support seems to allow a true separation, but POCO has some other limitations that I don't like.
Am I missing something, or does using EDMX have this drawback?
Are people using an auto mapper to convert between the entity model and another, clean, SoCced model?
thanks
Tian
I don't have a strong opinion on the Separation Of Concerns question, but I have used both the standard ADO.Net version of EF and POCO and it is not difficult at all to customise the output of the the T4 code generation script for POCO to address any concerns you have about the structure of the objects created. That sounds like it would probably be a good starting point for what you are looking to do.
Once you know you are looking for T4 templates there are quite a few tutorials and a lot of helpful SO questions that can give you an idea of what you need to do.
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/
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).
HI Guys,
I was watching these videos series about Entity Framework:
http://msdn.microsoft.com/en-us/data/ff191186.aspx
is that easy building application in real world programming??? and is it ....reliable...has good performance...
"I am a graduate.."
thanks
Entity Framework is a valid real world data access tool. It is very easy to get up and running with EF. You simply import (or create in EF 4) your data model. You then can rename it to make it more code friendly. And then you are off querying databases.
Performance
I have been on multiple projects that use it, some which require high throughput, others that have low performance requirements. Entity Framework out of the box is not the fastest solution in the world, so there are a lot of performance tweaks that have to go on, but its all do able.
Reliability
We never have issues with reliability. We have never had an issue with EF in general, its always data content related. Trying to insert duplicated data, etc.
Other Tangibles
EF follows a pattern which allows for you to do some fun stuff with templates and abstract classes. All entities inerit from a class, entities that have references inherit from other classes. All Entity Contexts inherit from ;) ObjectContext classes, which provide a base set of functionality that allows you to create generic DAO implementations that can be reused throughout the enterprise.
If you are using UI dev, you can also use Data Services that wrap EF, as a fast gateway to your databse. The only downside of this is that you dont have access to the full suite of the Entity Framework.