Should i Start with EF4 ?

Question

Hello,
i'm here to find some help about taking an important decision about EF.

In last few years i started developing with layers.
Until now i've written my own DAL and entity classes.
Now i've got a new project and i would like to use an ORM, i've never used one before.
My application will be quite little at the beginning.
I started looking some information about EF 1 and seems that looks quite good but not enough :-).


Seems quite hard to implement layers..am I wrong?
UI will be windows form by now, but maybe we'll switch to Silverlight.
I would like to have UI that call Service layer and Service layer that uses EF. Is It possibile?? how much is that difficult?

I've also read hat EF 4 has much of improvements, but now it's only in beta 2 and i need to produce something 'runnable' in about from 1 to 3 months.
Since i'm starting from zero, do you suggest me to start with EF 1 o EF 4? How much is stable NOW EF 4? and VB2010?
Is it possibile to have something redistribuitable developing with VS2010?
Can i start with EF 1 and than migrate to 4? Or do i need to rewrite something?

I really need to start in the right way and layering is very important for me.
Can you also suggest me a good way to start learning?

Thanks in advance
Paolo

Answer 1

Making use of EF4 and VS2010 Beta2 is a fairly safe bet, but if you need something production ready, you obviously do not want to develop on beta bits. If you need something that is merely demonstratable in a few months, then you are fairly safe.

Using the EF with Silverlight is supported, although there are a number of tricks, and you do need to go through a moderate learning curve, as you'll probably need to make use of self-tracking entities:
http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-self-tracking-entities-for-the-entity-framework.aspx

I certainly would not recommend EF 3.5 for your project.

We'll be happy to any questions you have once you get started.

---

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

Hello Noam,

Can you explain me a little bit of what self-tracking entities mean?
Aren't them included in beta2? I've quickly seen your link but seems quite too difficult for my actual knowledge.
By now user interface will be certainly windows forms. Do you think i will need self-tracking entities?

What do you think about my question reguarding layering? ('I would like to have UI that call Service layer and Service layer that uses EF.')

Last, if i am right, seem that i can create POCO classes. How can i? Do you suggest me to do it?

Thank you and sorry cause i'm very newbie.
..i'm downloading beta2 right now.

Paolo

Answer 3

Paolino, 

Entity Framework – the same as other Object/Relational Mappers – has been designed to detect changes automatically on entities that are being tracked by some sort of change tracker/session/state manager. With this mechanism, it is possible to address many application scenarios, and even implement logical tier separation.  

For instance, you could create an in-process DAL (i.e. using the Repository pattern) that returns tracked objects obtained through queries and exposes methods to add new objects, delete existing objects, and also a method to commit all changes to the database. Components above the DAL wouldn’t need to know how modifications are being detected by this DAL, and they would simply manipulate entities returned by it and later ask the repository to commit the changes.  

That said, if the application you are working actually requires multiple physical tiers to exist (i.e. when you move the client tier to Silverlight) and changes will be performed on the client, then you cannot rely on the automatic change tracking mechanisms of the O/RM to record changes in your entities. 

Self-tracking entities provide an easy to use alternative for such a scenario. Self-tracking entities preserve information about original values and about the original state of relationships as changes are made on the client, so that the changes can be easily replayed back on the server.  

Self-tracking entities requires that you share entity types between the client and the middle tier, and therefore their use is only advisable in scenarios in which you own both ends of the “pipe” (i.e. you don’t have a public facing service that other non-trusted clients can talk to), and if for you it is relatively easy to keep the entity types used on the client and on the server in sync.  

In many other scenarios, i.e. when you don't own both sides of the 'pipe', it might be preferable to establish a simple contract between the client and the middle tier and only interchange messages that are expressed in terms of Data Transfer Objects and not actually share entity types.  

Yet, if the service side of your application can be easily modeled as a set of resources to which you apply standard insert, updated and delete operations, you may want to take a look at ADO.NET Data Services, which also works with Entity Framework and supports Silverlight on the client side.  

Incidentally, we released today a new version of the Feature CTP that includes a new version of Self-Tracking Entities and can be used with VS 2010 beta 2. See the announcement here:

http://blogs.msdn.com/adonet/archive/2009/11/04/ado-net-entity-framework-community-technology-preview-released.aspx. 

I would recommend taking another look at the self-tracking entities walkthrough that Noam referred to until we publish an updated version. 

Hope this helps,

Diego