views:

64

answers:

1

Hi,

If I already have domain classes, and I want to be able persist them using EF via a model first approach how do I do this?

For example do I go to the EF designer (in VS2010) and create the model and generate the classes, then go to these EF classes and somehow manually modify them? But then would there be an issue if I needed to change the model and re-create database TSQL from the model for updates?

What's the easiest approach?

EDIT - In my case I've got some base classes that do graph navigation - I was hoping I could leave (a) my graph traversal routines in the business logic assembly, e.g. NodeBase, RelationshipBase etc, and then (b) have my EF persistance in a separate EF assembly. Any advice on this specific scenario I have?

EDIT 2 - Actually I note I note the following template options from "Add Code Generation Item.."

  1. ADO.NET C# POCO Entity Generator Template - Online
  2. ADO.NET Self-Tracking Entity Generator - Local
  3. ADO.NET Entity Object Generator

I'm guessing the #3 one is the default that comes with VS2010. Anyone across #1 and #2 and which might be best to assist in my goal? i.e. Having an existing set of domain classes with methods that already inherit from other classes (i.e. noting with the current EF generated entity classes they seem to already have to inherit from EntityObject)

+1  A: 

The generated classes are all partial. So if you have the same namespace and same Entity/Class names it's fairly easy to merge an existing set of classes with a model-first set of entities. Simply put partial on your class and remove all the properties that are implemented by the Entity framework generated code.

Hightechrider
You'd create your own partial class files and extend those, I believe. In the same vein, you can create your own t4 template by copying the initial one after you generate, then use your copy thereafter. Open up [MyModel].edmx in an XML editor and knock yourself out.
Superstringcheese
Can I change the class it inherits from however? Ie from the default EntityClass or whatever it is (I'm out an about at the moment)
Greg
@Greg No, using this approach the hierarchy needs to be the same. *Easiest* approach would be to make the hierarchy the same and go down this path. If you can't then you will need to go read up on T4 templates, Poco, ... If you have code shared between your top-level entities maybe you can use an Interface instead and a separate implementation of that interface to get the common functionality, e.g. I have ITaggableObject which many different objects implement, all simply delegating the work to a shared TaggableObject extensions class.
Hightechrider
In my case I've got some base classes that do graph navigation - I was hoping I could leave (a) my graph traversal routines in the business logic assembly, e.g. NodeBase, RelationshipBase etc, and then (b) have my EF persistance in a separate EF assembly. I'm not sure this is really possible then. Any advice on this specific scenario I have?
Greg