Entity Framework "Code Smells" Question

Question

I'm a fan of Ef and want to use it but I'm not necessarily a fan of how associations work per-se. If I have a simple lookup table containing maybe 3 rows in it and would typically be treated as an enum in code, I don't like that I effectively have to do this to assign a value using the associating in EF:

myEntity.MyLookup = db.MyLookups.First(ml => ml.MyLookupId == 5);

I mean, not only does it look funky but it also then queries the db again just so I can effectively assign the value "5". I know this is also possible by setting the EntityKey via MyLookupReference but that seems even smellier.

My question is, is it possible to get rid of the Store representation of an associate and just treat everything as a scalar on my entities there by not having the navigation properties and allow me just to do joins when necessary?

Also, if this is feasible, does it have any impact on who entities are tracked or anything like that? Thanks!

Answer 1

I think this is another reason for keeping Business Logic separate from data access layers. You may already do this, of course.

As an example, if you have a User table, and a UserTypes table. Your data layer needs to deal with this, but the business layer doesn't need to know about it, assuming you have some kind of factory method in your data adapter that takes a user and a user type and converts them to an Administrator (for example).

Not sure if this helps, just thought i'd give an opinion.

Answer 2

Foreign key values are a pain in EF v1. The way you're doing it above is the only way unless you're prepared to create an EntityKey yourself.

EF v4.0 will do away with this headache with "FK Associations." FK Associations are updatable scalar values that represent the relationship.