|
Ting wrote: "When you do migrate, make sure to include the foreign keys as properties on the entities"
Let me elaborate a little. Your choice of whether or not to expose FK ids goes beyond the visibility of the FK Id property itself ... it goes to how association XML is generated in the EDMX. I haven't taken the time yet to decypher the details yet but I know there's a snake in the grass somewhere. And I know you have to make the decision to expose FK Ids early in your EDM design ... as I 'll explain below.
There is no switch in the EF Designer UI to throw it from one mode to the other. The only place I've found IN THE UI where you can make this choice globally for the model is in the Wizard ... when you pick the "Generate from Database" option.
[Aside: you can "throw the switch" in the EDMX XML but (a) why do it the hard way and (b) doing so will only affect subsequent association generation; it won't "correct" existing associations. It will be too late later.]
With "400+ tables" to convert, your only reasonable conversion path is to use the EF Wizard to "Generate from Database". You can do it in chunks (Using the Wizard to "Update from Database" to add the next round of entities) ... or shoot for the moon and do it all at once ... which is what I'd probably do.
MAKE SURE that you have checkmarked both "Expose FK Ids" and "Pluralize"!
There are other differences between DF 2009 (5.x) and DF 2010 (6.x) to work through. You might want to get your feet wet by converting a "Hello World" scale application first ... even if this means writing such an app in DF 2009 first.
Assuming you have that under your belt, you can bring in your new model. Compile. And analyze the inevitable compiler errors. What might these be:
Namespace / Custom EntityManager / DataSource Key
You may have to change these values.
The namespace of generated classes will be the default namespace of the project. That's set in the project properties. You can change that at anytime and regenerate your entity classes.
Set "EntityManagerName" and the "DataSource Key" are at model-level in the "DevForce" section of the EF Model Browser's property sheet.
Pluralization Differences
The EF Wizard pluralizes a little differently than we do. You'll pick out those differences right away and use the VS refactoring tools to clean those up.
Suggestion: Get http://www.jetbrains.com/resharper/ - ReSharper if you don't have it already. It is far better at refactoring than VS 2010.
Massive Renaming
Perhaps your DBA forced you to prefix table and column names (e.g., INV_Invoice, PER_Person, COM_Company). You probably went through a lot of effort to strip off those prefixes in your DF 2009 model. You'll have to do it again.
I know of one tool out there that might help with massive renaming: http://www.huagati.com/dbmltools/ - http://www.huagati.com/dbmltools/
Or you can apply some form of regex search-and-replace tool to your EDMX; I'd give that a look first.
No more "_fk_" Foreign Key Ids
"Company_CompanyId_fk_Id" becomes "CompanyId". Global search and replace accordingly.
Inheritance
Did you use that in your old code? You'll have to rebuild your inheritance relationships. Hope you don't have too many of them. It's just basic blocking and tackling. The options are the same. The VS 2010 designer is more supportive.
Property Access
If you any of your mapped properties were other than "public", you'll have to reapply those changes. Search your original generated code for "internal", "protected", "private"; these will almost always front properties you modified in the DF 2009 Object Mapper.
Important! If you intend to use your model in Silverlight application and you want a property to be other than "public", make it "internal". We can find "internal" properties. Silverlight prevents us from finding "protected" or "private" properties.
New Option: You can delete one side of a navigation property. You really shouldn't be able to navigate from "Gender" to "Person"; delete the Gender's "Persons" navigation property.
Validation Options
If you messed with these you'll have to reapply them. You can change the model level default in the "ValidationAttribute Mode" setting in the "DevForce" section of the EF Model Browser's property sheet.
Property level validation options are different in DF 2010. The "Validation" option under the "Attributes to Suppress" setting may do the trick. Let us know if you get stuck here.
Unmapped Abstract Entity Classes
In both DF 2009 and DF 20010 you can put your own logic in a custom base class that isn't mapped to anything. Many folks create their own "EntityBase" that sits on top of our "Entity" class and just below their concrete entity classes (e.g., "Customer", "Employee").
You'll have to tell DevForce about this if you're using a base class.
If you have one type that you use for alll (or almost all) entities in this model, type the name of this "Default Base" class into the "Injected Base Type" setting at model-level in the "DevForce" section of the EF Model Browser's property sheet. Remember to include the namespace if your base class is in an assembly other than your model project (e.g, "CommonEntity.EntityBase"). Your base class must inherit from IdeaBlade.Entity ... unless you were modeling with POCOs instead of doing code generation (another side topic).
In DF 2009 you could insert unmapped base classes in the middle of an inheritance tree. For example: Apple -> FruitBase -> Produce -> EntityBase -> IdeaBlade.Entity. "FruitBase" is your abstract class between two mapped classes, "Apple" and "Produce".
You can't do that in Entity Framework v.4 and therefore you can't do that in DF 2010. You'll have to come up with another approach to specify common "Fruit" behavior for your apples and oranges. I have some compositional strategies in mind.
You can stack multiple base classes but they all have to reside below the first mapped entity ... Apple -> FruitBase -> EntityBase -> IdeaBlade.Entity.
Unfortunately, you can't specify different abstract base classes for different mapped entity classes through the UI. You can't have concrete fruit types inherit from "FruitBase" while concrete meat types inherit from your custom "MeatBase". You'll have to either post-process the generated code (which will be wiped out the next time you regenerate) or customize our code generation.
Custom Code Generation
The (almost) universal solvent is custom code generation. It is really easy in DF 2010 to customize the code we generate. We are using T4 templates for code generation. We've got a nice customization API over our T4 so you don't have to wrestle with that technology.
Code generation customization lets you intercept the EDMX XML, interpret it yourself, and emit your own code. You might get out of some jams with this technique.
Such are my current ideas on the subject. It's a far cry from the automated conversion tool you seek. I bet it will cost you a day or two to convert 400 entities. The compiler will surely help; just about everything that will go wrong will be caught by the compiler.
Do let us know ... we are curious.
|