Feeds:
Posts
Comments

Posts Tagged ‘entity’

Scenario: Important meeting! Too much coffee! Bad lighting! In walks the killer! Wait…

No, that’s wrong. In walks Visual Studio 2010 Beta 2 with an inability to open an EDMX created with Visual Studio 2010 Beta 1, asking if I’d like to open the file in an XML editor. Ack! A previously printed paper diagram (for the meeting) and a bit of time later I resolved the differences between my EDMX and a test EDMX created with Beta 2.

  1. The Schema tag,next item after <edmx:StorageModels>, had the correct xmlns property but was missing entirely the xmlns:store property. Adding xmlns:store=”http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator&#8221; was required.
  2. The Schema tag,next item after <edmx:ConceptualModels>, had the correct xmlns property but was missing entirely the xmlns:annotation property. Adding xmlns:annotation=”http://schemas.microsoft.com/ado/2009/02/edm/annotation&#8221; was required.
  3. Changing all “store:” prefixed properties of elements within  ConceptualModels to be “annotation:” prefixed.
  4. Swore at Microsoft a little for giving me the “prividledge” of hand-editing a 2400 line xml file.

A save and compile later I could open my diagram and proceed. Hope that helps!

Read Full Post »

This looks very useful for anyone (poor wretch) wrestling with the Entity Framework.

EdmGen2 is a command-line tool for the Microsoft ADO.NET Entity Framework. The tool can be used as a replacement for the EdmGen.exe tool that ships with the .Net framework 3.5 SP1. EdmGen.exe can only read and write the CSDL, SSDL & MSL file formats. However, EdmGen2.exe can read and write the EDMX file format used by the Visual Studio design tools. Additionally, EdmGen2.exe can translate between EDMX and CSDL, SSDL & MSL formats, and the source code can act as examples on using the tooling APIs defined in the System.Data.Entity.Design assembly.

via EdmGen2.exe – Home.

Read Full Post »

Interesting if somewhat scathing discussion of using the Entity Framework for n-tier applications from the developers/designers of the next version of the Entity Framework. The feedback has inspired me to look at nHibernate again, and makes me wonder if the Entity Framework is really as safe a bet as one would assume Microsoft’s implementation of a technology would be.

The first version of Entity Framework provides convenient ways to load, manipulate and persist objects and relationships. As with many other O/RMs, Entity Framework has a state manager that tracks every change made. Existing objects are typically loaded first from the database, later modified, and finally the changes are saved back to the store.

Another feature, full graph serialization, makes it very easy for developers to ship around object graphs representing snapshots of the current state of the world, across execution boundaries.

The next version of Entity Framework will also support Persistence Ignorance. Therefore object graphs can now be made of POCO instances, which WCF now also supports.

Nonetheless, there is a task that belongs in any N-Tier application that still requires a great amount of work for developers using EF: decoding messages that represent state changes performed by the client, meant to be processed or persisted by the service.

via Entity Framework Design : N-Tier Improvements for Entity Framework.

Read Full Post »