Controlling naming of properties

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.