开发者

Entity Framework POCO Does Not Fit Nicely with Domain Objects

开发者 https://www.devze.com 2022-12-10 21:34 出处:网络
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:

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/wan开发者_开发知识库t 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?


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.


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).


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消