With the current CTP of the ENtity Data Model Tools, there is no way to automatically update or refresh the EDM when a change is made to the data store.
One of the beauties of the EDM is that fixing up the EDM in these cases is not only easy, but it doesn’t need to have any impact on your application, because you can leave the conceptual layer which you program against in tact.
Here’s an example of a minor change (inspired by a question in the forums) in the database and what you need to do today (I keep saying that because I don’t know what the next increments of the tools will bring) to fix up your model.
Scenario: DBA changed fname and lname columns in the Customer table to firstname and lastname.
In a non-EDM application this could be dealt with in a few places, depending on how your db and app are architected:
- Modify any stored procs and views that spit out those fields so that they now know how to grab firstname and lastname but continue to surface them as fname and lname.
- Modify the data layer of your application (and redeploy it) so that it now is aware of firstname and lastname. Modify your business layer so that it knows that the properties have to look for firstname and lastname.
- If your app doesn’t use these layers (hopefully that’s a big “if”), then you need to make those changes even closer to the UI.
In an EDM here’s how you would solve the problem.
- Change the column name in the storage schema.
- Change the column name in the mapping schema for the two mappings that link those fields.
Step by step
Open up the EDMX in the XML Editor. (Right click on EDMX in the solution explorer, choose open with, then XML Editor).
You can do all of this in the raw xml, which to me is easy. THe current designer does let you change the mappings. SO I will show how to do #1 in the raw xml then #2 using the designer.
Locate the node for the Storage Model. You can find that quickly by searching for it’s comment “SSDL Content” or it’s name “StorageModels”.
IN there, locate the entity that represents the table with the change.
Edit the name of the entity.
Close the EDMX and re-open it in the designer.
Another part of what makes EDM so great is that when I first created this model, I didn’t like “fname” and “lname” and changed them in my conceptual layer to FIrstName and LastName. At that point, they were properly mapped to the fname and lname columns and all was well. This is what the mapping looked like before I started making the changes. YOu can see that my db column was called “fname” and my property in my conceptual layer was “FirstName”.
Now that the dba decided to change the column names in the database as well, I just need to remap my FirstName and LastName properties to the newly named database columns.
Select the Customer Entity and then open the Entity Mapping Details. (If you don’t see that page, right click on the model (in the white space) and select SHow Entity Mapping Details.)
The mapping details shows you the columns from the storage entity first (e.g. the database table) and then on the right which property in your conceptual entity that column is mapped to.
You’ll see that the columns fname and lname are gone from the mapping and it is now showing you the FirstName and LastName from the store schema, but they aren’t mapped to any properties in your conceptual entity.
Just drop down the value/property list and it you will see all of the properties in the entity that this is mapped to.
That’s it. And the impact with respect to deployment is that the new versions of the xml files that describe the schema need to be deployed to whatever tier the data layer that needs to know how to do the mappings. The client apps most likely just have the classes that were derived from the conceptual layer and since we didn’t change that part, they don’t need to know anything and can go on their merry way.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!