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.
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'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).
I currently use the Entity Framework designer to generate my persistance objects and I also user POCO view models for the ASp.NET MVC view.
I've read and listened to a lot of people talking about the good support for POCO's in EF4 as well as POCO's in general but I can't seem to work out what advantage, if any I'll get from using them.
In our application, we WILL be using SQL Server so it's not like we need so separate out for different databases.
Why would I want to use POCO's as opposed to the designer generated classes?
POCO offers better extensibility/reuse of your Domain Model as you're not tied to any specific ORM framework.
Answered here :What are the 'big' advantages to have Poco with ORM?
Easier to unit test
I find when you have many entities (100+) using the designer is painful and POCO objects are easy to create and maintain.
With POCO's you can "Code First"
http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx
+1 for with POCOS you can code first. In fact you can create and test your entire application before you even write your first line of data access code. This is how it should be, it's a perfect application of the SRP. Your domain object should not know or care how they are being persisted.
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.