• You will need to run the DEF Object Mapper to create a "domain model" project based on one or more Entity Data Models (EDMX).  The Object Mapper will consume the EDMX files as is, and can also help make the entity model more usable with its pluralization feature.  Once created, the domain model and entity model will be symmetric - updates to one will either cause an automatic update to the other or a prompt for an update - so you can use either or both the EDM Designer and the Object Mapper when working with your model.
• In your client code, you will reference the domain model and not the EDM - which is now considered "server-side" only.  In n-tier with DevForce, the entity model resides on the server only.
• You will need to change from using the EF ObjectContext to the DEF EntityManager.
• EF query syntax is supported in DEF so your queries should require little to no modification.
• There are a few changes in the high-level API between DEF and EF: 
• DEF uses AddEntity() as opposed to EF AddObject()
• DEF uses entity.Delete() as opposed to EF DeleteObject()
• DEF doesn't really have the EF Attach() concept, but the closest would be ImportEntities()
• DEF SaveChanges() allows for saving a subset of items while EF SaveChanges() does not
• If your business logic is contained within your EDM project it will probably now instead go in either the server-side domain model project or another assembly to be deployed to the server.
• Other changes may depend on the complexity of your application and requirements.

I should note that DevForce EF does not support LINQ to SQL.  DevForce EF RC1 is built against ADO.NET SP1 Beta and will not work with EF Beta3, since there were breaking changes between these EF releases.  The next release of DevForce EF, supporting the RTM of ADO.NET SP1, will be at the end of August.

Hi,

I'm currently evaluating DevForce EF (Haven't started any development yet with it). I found your product via a Webinar and was impressed by it's functionality. We have build an application in C# with the Entity Framework (is life) and we've run into several issues that are going to take us a lot of time to resolve. One of them is caching, which I've seen is implemented into the DevForce EF Framework amongs many other functionality we could defenitly profit from.

Let me tell you about the application and then come to my question.

In principle it is a 3 Tier Client/Server Application, fully written in C#.
We've used the Entity Framework as our Datalayer (Beta 3).
The Application is divided into 2 Programs.
1. Is a Server
2. Is the Gui written with custom Controls
Communication between the Client and Server is done via Remoting.
The Server can serve many Clients.
The Business Logic is in the Server.
Data Retrieve for the main part is done using LINQ to Entities and LINQ to SQL. Some Retrieval is done via SQL Strings (the old fashion way).

Now for the question. If we implement our own caching mechanism I estimate that we are going to burn more time and money than we would when we would buy DevForce EF. Having said that. I don't know how much time would be involved getting the Application refitted with DevForce EF. Now I don't want a commercial answer, just give me the facts. How hard is it to refit our Application with DevForce EF.

Cheers,
Paul Sinnema.