VISUG Event : Entity Framework & WCF

Hello,

Kurt Claeys gave a presentation about using the Entity Framework (EF) in a distributed scenario (Service oriented with WCF, Tight coupled Client-server) for the Visug , the Belgian Visual Studio user group.

His presentation was based on his personal research into the subject so he didn't gave immediately all the answers. Instead he showed us via concrete examples which difficulties he encountered during his endeavor.

The reason for going N-tier and the way to achieve this were out of scope for the session but decoupling was the key concept he used to convey this requirement.

After a very quick introduction into WCF and the EF, Kurt showed us the challenges you are confronted with if going this route and how WCF, EF or something else could provide a solution: Serialization of object graphs, contract sharing , … But the biggest hurdle in the current implementation seems to be change tracking.

In EF, a special mechanism called the ObjectContext, keeps track of all the things you do with the entity instances you retrieve through the EF infrastructure. This means the entity identification , the relationships ….and also the changes you make to the entity instances or the relations between them. Without the objectContext the EF infrastructure cannot create the necessary insert/delete/update statements for your data store.

Now a typical Service-oriented WCF service (cfr. 4 tenets of SOA ) is stateless in nature. This means that an operation that enables to retrieve an object graph through EF registers this action with the EF objectContext , but due to the nature of the service operation, the objectContext doesn’t stay around.

Kurt showed in some examples what this means for us as a developer . He also tried to come up with solution candidates to the problems like for example re-fetching the entity again and using special functionality from the objectContext the apply the changes. It worked but only for a single entity instance without relations. If you would like to go further …you had to do it yourself. Another solution candidate was to re-attach the object and apply all the changes to the re-attached object . If you had relations….you get the picture: DIY was the common factor in the candidate solutions.

There are some efforts in the EF community to give support of object change tracking in a distributed scenario but some of them are not active anymore and some are more research like efforts to look for solution.


Kurt concluded his presentation with what is coming in Vnext of EF , as told on PDC 2008.

What I remember is that if you’re going to use EF in a distributed scenario you should clearly do your homework first and recognize the potential difficulties you about to face in your situation and come up with a strategy to solve them.

Feel free to check the Visug site if you want to browse through the presentation. Maybe Kurt will also post his examples so you can try them out?

What are your experiences with EF?

Thanks for reading,

Best regards,

Alexander

Comparing to Linq to SQL

Hello,

Recently I took some time to investigate Entity Framework (CTP3) and Linq to SQL (RTM) further. While going through the examples I compiled following list with benefits & concerns. Maybe you have made a list for your own? Maybe you would care to comment. Please do so!

Linq to SQL

Benefits

• Already available in VS2008 RTM
• Generation of partial classes based on the database schema
• Relationship are also detected and modelled as special properties in the entity classes
• You work with these entity classes in you application.
• Generated classes can be augmented with custom methods
• Generated classes can be augmented with partial methods
• LINQ support to specify queries
• Dynamic generation of SQL (you do not have to write SQL your self)
• Databinding support
• Lazy loading (default) and immediate loading flexibility
• Updating only changed columns
• Optimistic Concurrency support through mapping directives.
  

Concerns

• Basis mapping capabilities ( 1 table -> 1 Entity)
• Only SQLServer
• Distributed application requires special attention (dataContext)
• Designer lets you start from a blank model but I haven't found something to create a database schema from the entity model.
• Serialization of entity classes only set if generated with SQLMetal command-line tool option.

Entity Framework

Benefits

• Generation of partial classes based on the database schema
• Designer lets you start from a blank model but I haven't found something to create a database schema from the entity model.
• You work with these entity classes in you application.
• Generated classes can be augmented with custom methods
• LINQ support to specify queries
• Dynamic generation of SQL (you do not have te write SQL your self)
• Databinding support
• Normally foreseen to accommodate multiple database systems
• More flexible mapping capabilities than Linq To SQL (fine-grained entity model, Inheritance mapping flexibility, etc)
• Generated classes by default serializable
• Data driven Object-modelling point of view
• Lazy loading (default) and immediate loading flexibility
  

Concerns

• Promised to be shipped with SP1 VS2008
• Distributed application requires special attention (ObjectContext)
• Designer lets you start from a blank model but I haven't found something to create a database schema from the entity model.
• In the designer you can not add behaviour in the model( somewhat normal because it is a DSL for data persistence but still....). Entity are now more geared towards a data-container role.
• Two flavours to query the databases system (linq to entities and entity SQL). At this moment I'm not very sure when to use which.

So if you have other points of interest or remarks , I would like to hear them.

Thanks in advance.

Best regards,

Alexander

Unit testing ADO Entity Framework

Hello,

I was playing with the ADO.NET entity framework beta 3 that I installed on the Rosario November 2007 CTP and I had some problems making unit tests. I kept getting the follwing error.

System.Data.MetadataException: The specified metadata path is not valid. A valid
path must be either an existing directory, an existing file with extension
'.csdl', '.ssdl', or '.msl', or a URI that identifies an embedded resource

When you use the wizard to create a model several "hidden" files are generated for you; .csdl, .ssdl, and .msl files. The information contained in these files is encapsulated in the .edmx file but the files .csdl, .ssdl, and .msl files reside in the bin\Debug or bin\Release directories of the solution. Apperently these files are still necessary at run-time. There not embedded in the assembly.

In a connectionstring you specify these files in the metadata part :

connectionString="metadata=.\Northwind.csdl.\Northwind.ssdl.\Northwind.msl

When you're using for example the VS test framework, the test infrastructure copies the assemblies to a certain test folder (isolation). If you have an app.config or use custom files in your code, you must assure that the test framework put these file in that particular test folder.


Now the .csdl, .ssdl, and .msl are also not copied to that test folder automatically. I used the deployment feature of the VS test environment. I specified the three files and now there copied to the test folder.

Maybe there are other ways? Let me know!

Best regards,

Alexander