views:

25

answers:

1

I have an table called Invoices with a column named Vendor. The Vendor column is a FK reference to a Vendors table with the PK being Id.

My dbml creates the appropriate objects...Invoice and Vendor. However, my Invoice object has both a Vendor property (as a String) and a Vendor1 property (as a Vendor object).

I thought it would have to do with my column name matching the referenced object name but after changing the column to VendorId and recreating all the dbml objects the repeated property was still there. Looks like it is because of the column matching the object...it creates Vendor to hold the String value and then Vendor1 to reference the Vendor object. Why does it not just create the single object reference?

Thanks

+1  A: 

It's not a repeated property - it's two different properties for two different purposes.

The Vendor property corresponds to the data in the column in your database.

The Vendor1 property represents the foreign key relation, i.e. the join to another table. It's called Vendor1 because the name Vendor was already taken (using VendorId for the column name is a good idea). The Vendor1 object won't be fetched by default unless you actually use it. Having this property available makes it easier to formulate queries that would otherwise require you to specify a join.

Both properties are useful to have on your object.


To answer your updated question:

Linq has to fetch the vendor id anyway whether you use it or not - just in case you might use it. Since it has already been fetched it seems convenient that it is also visible in the interface. If you wrote obj.Vendor1.Id instead of obj.VendorId, it would cause the Vendor1 object to be fetched from the database unnecessarily. So there is also a performance implication.

Mark Byers
Thanks for the response. You answer is what I thought it would be. Maybe it is just me...but the whole "1" appended to the property makes me cringe...
Jason