Anyone using Entity Framework (EF) for data layer?

Question

Is there anyone using the EF for the data layer in their WPF application? I was considering a new client with WPF for an existing application and I might also look at building a new data layer because of some issues with the legacy one. The reading I did on the EF make it seem like a fast solution for my situation but I have yet to see any examples that show a good disconnected data layer with EF and WPF. The only examples I've seen were some introduction videos were the data access was mingled into the view models. I can't think of a reason why the two wouldn't work together but I'm just learning both so it's hard to guess at this point.

Answer 1

Entity Framework works just fine in WPF for Data Layer access.  The only real question you need to ask is how large your project is and what kind of performance you need.  EF is considerably slower than direct access to a database.  If your project has performance considerations don't use it, it has a lot of overhead.  EF is very helpful with large projects as it simplifies talking to the database.

---

Michael Stacie

Answer 2

One for view (UI), one for Data. EF provides the Datafor View, and we can use WPf binding to build the bridge between the Data and the UI control.

EF or other Data Layer technic, just provides the data. If you did a good design for your application, we can replace the Data Layer without changing any code.

Please check this video: http://msdn.microsoft.com/en-us/vbasic/Video/dd776537 a simple sample to build a EF WPF application.

Sincerely,

---

Bob Bao [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 3

Most of the simple examples of EF don't show any abstraction of the DAL. I know it's just an intro example but ones like this  http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx make it seem like the DAL needs to reside in the client code.

Let me take a look at the video you linked and see if that clears it up before I reply with more.

Answer 4

On 8/30/2011 6:25 PM, pretzelb wrote:

> Most of the simple examples of EF don't show any abstraction of the DAL.

> I know it's just an intro example but ones like this

> http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx

> make it seem like the DAL needs to reside in the client code.

>

> Let me take a look at the video you linked and see if that clears it up

> before I reply with more.

>

 

Each one of the E-Commerce source code solutions on the front-end are

using the same WCF Web service, BLL, DAL with Linq-2-SQL or EF on the

back-end.

 

http://www.dofactory.com/Framework/Framework.aspx

 

Answer 5

Thanks for the reference to the E-Commerce examples but I was hoping for a free sample.

I looked at the video again (http://msdn.microsoft.com/en-us/vbasic/Video/dd776537) and I think it's what confused me from the start. The EF is presented as being put into a DAL but then the sample goes on to write the data access code on the client side. While I understand there are time constraints for sample code to me this isn't showing a true DAL. Switching to a different data access method would require client code rewrites on a large scale.

But I think what I need to do is try the design idea in that video but adding a classes like Customer, Order, and Product to the DAL to provide a layer of abstraction to the WPF. Might need a third project for infrastructure to share interfaces between the two and for a DataRepository object class . At least I think that approach would work. The CustomerRepository in the Infrastructure would implement  iCustomer, which in turn has a GetAllCustomers() function returning a list of Customer objects. The CustomerRepository handles calls to the EF project and conversion to interfaces. The client could then create an instance of the CustomerRepository and call GetAllCustomers. If a change to the DAL was needed then only the Infrastructure project would change (and the DAL). I'm just not sure how it would look for the abstracted Infrastrucuture being able to manage the EF links. I might need to see if I can try a simple example. 

Answer 6

On 8/31/2011 12:48 PM, pretzelb wrote:

> Thanks for the reference to the E-Commerce examples but I was hoping for

> a free sample.

>

> I looked at the video again

> (http://msdn.microsoft.com/en-us/vbasic/Video/dd776537) and I think it's

> what confused me from the start. The EF is presented as being put into a

> DAL but then the sample goes on to write the data access code on the

> client side. While I understand there are time constraints for sample

> code to me this isn't showing a true DAL. Switching to a different data

> access method would require client code rewrites on a large scale.

>

> But I think what I need to do is try the design idea in that video but

> adding a classes like Customer, Order, and Product to the DAL to provide

> a layer of abstraction to the WPF. Might need a third project for

> infrastructure to share interfaces between the two and for a

> DataRepository object class . At least I think that approach would work.

> The CustomerRepository in the Infrastructure would implement iCustomer,

> which in turn has a GetAllCustomers() function returning a list of

> Customer objects. The CustomerRepository handles calls to the EF project

> and conversion to interfaces. The client could then create an instance

> of the CustomerRepository and call GetAllCustomers. If a change to the

> DAL was needed then only the Infrastructure project would change (and

> the DAL). I'm just not sure how it would look for the abstracted

> Infrastrucuture being able to manage the EF links. I might need to see

> if I can try a simple example.

>

 I don't particularly care for the Repository pattern. I use a form of a

Object Manager pattern. The object manager is used in the BLL and DAL to

work with a Customer object as an example for all CRUD operations with

the Customer EF Entity on the model.