Print Page | Close Window

Controlling naming of properties

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1581
Printed Date: 06-Apr-2025 at 5:37pm


Topic: Controlling naming of properties
Posted By: downeytim
Subject: Controlling naming of properties
Date Posted: 10-Dec-2009 at 11:04am
I am really diving into the objects created by the Object Mapper and am finding some things I don't like. In the previous version of the IdeaBlade object mapper if I had a column, tied to a foreign key, name AccountDebitTypeId the business object column was named AccountDebitTypeId.  In the new Object Mapper the AccountDebitTypeId column ends up as AccountDebitType_fk_TypeId.
 
The foreign key is from LoanTerm.AccountDebitTypeId to AccountDebitType.TypeId.  I see where it is getting the naming convention from but this is going to break so much existing code I can't believe I will ever get my application running again.  I have over 500 Db tables with relations out the you know what.
 
Can I control this behavior?


Replies:
Posted By: GregD
Date Posted: 10-Dec-2009 at 4:04pm
The current version of the Entity Framework discourages the use of foreign keys altogether. Its dogma, if I may presume to put words in its mouth, is that foreign keys are an internal implementation mechanism that the developer ought not to know about or care about, much less use directly. Thus, like DevForce old and new, the EF model not only supports, but generates, nested properties, and lets you get the Orders associated with a particular Customers by saying aCustomer.Orders.

In the framework's Entity Data Model, foreign keys are hidden altogether. So you have to form your queries a bit differently than in the past. Thus, instead of saying

    objectContext.Orders.Where(o=>o.CustomerId == aCustomer.Id);   // (non-existent Order.CustomerId foreign key used

you say

    objectContext.Orders.Where(o=>o.Customer.Id == aCustomer.Id);   // no foreign keys used

The latter way of doing things depends upon the existence of appropriate navigation properties (like the Customer property on the Order type), but those are guaranteed to be available because the EF code generator creates them wherever it sees a relationship defined between two tables in the backend database.

An important design goal for the current version of DevForce was consistency with the Entity Framework and its conventions. We did not want to encourage people to do things in a non-EF way, nor to create obstacles for those migrating to DevForce from pure EF. On the other hand, we found that we absolutely had to have the use of foreign keys for some of our internal operations; and we reasoned that some of our customers might share this need.  So our compromise was to expose the foreign keys (which we burrow deep into the Entity Framework to get) in our model, but to give them the "internal-looking" _fk_ names that you see.  We haven't provided a mechanism for changing those names.

FYI, in Entity Framework 4, due for release with .NET 4 on March 22 of next year, foreign keys return. There was quite a bit of pushback to Microsoft on this issue.


Print Page | Close Window