views:

233

answers:

3

I have taken a model first approach for a project i'm working on. An example of a class relationship is shown as follows, pretty strightforward:

public class Product
{
  public int Id { get; set; }
  public string Name { get; set; }
  List<Photo> Photos { get; set; }
}

public class Photo
{
  public int Id { get; set; }
  public string Path { get; set; }
}

The database schema will roughly be:

--------------
Products Table
--------------
Id int,
Name Varchar

------------
Photos Table
------------
Id int,
Path varchar
ProductId int FK Products.ID

A Product can have Zero or more Photos.

Now when i try to plug is my ORM of choice (Entity Framework V4 - Poco approach) iam forced to map my relationships in the domain model!

public class Product
{
  public int Id { get; set; }
  public string Name { get; set; }
  List<Photo> Photos { get; set; }
}

public class Photo
{
  public int Id { get; set; }
  public string Path { get; set; }
  public int ProductId {get; set; } //Foriegn Key
  public Product Proudct {get; set; } //For uni-directional navigation

}

Firstly, i dont need/want uni-directional navigation. I understand this can be deleted. Secondly, I dont want the Foriegn Key declared in the Photos class.

I dont think this is true POCO/persistence ignorance if i must define database properties in the Domain Objects?

Do other ORM's behave this way?

A: 

Why don't you want to have Photo.Product property? If there is no such property, it seems one photo can belong to several products and since database schema should be more complex (with auxiliary table).

Alex Kofman
In the domain model the product and photo is defined using a composition relationship. Client will access the collections to get the photos. I see no need to to have Photo.Product/Photo.ProductId in the photo class as they imo are purely for the relational database . I think something can be defined at the the conceptual model but not sure what.
A: 

The relationships don't have to be two-way, and don't have to be public (if you use true POCOs, not proxy types). You've said quite a bit about what you don't want in your code, but can you be clearer about how you do want to define the relationships? It has to go somewhere. Where would you like to put it? There are many options.

Craig Stuntz
I want to use the relationship described in the first example. Given that example is it possible to have an ORM (any orm) understand the domain model and automatically track entities etc? Can this be defined in the conceptual model?
Are you doing code-only?
Craig Stuntz
I am using the EF v4 feature which allows me to turn off default Code Generation and plug in my own poco objects. http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx
EF v4 has *two* ways to do this. Self-tracking entities and proxies. I'm asking you to be precise about chat you're doing and how you're configuring code-only.
Craig Stuntz
+1  A: 

I found the answer. Using the wizard, there is an option to "Include foreign key columns in the model" - Uncheck this box and you will a clean conceptual model without FK.

Make sure Code Generation Strategy is set to none in the properties window.