views:

123

answers:

2

I have a EDM that was wizard generated from an SQL 2005 Express database. For example, I have a table named Projects with a relationship to a table named People. Projects have two relationships on the People table primary key as foreign key in the People table (ChamipionID and LeaderID).

I have cleaned up all of the names for the Entities, Entity Sets and Associations and verified that the Association mappings are what I expect them to be.

When I write a Linq to Entities query against this, the association "Leader" which is mapping LeaderID to PeopleID of data type int64 (long) is always returned as null in the View Model in an MVC 1 website.

for example

var object = (from p in _entities.Projects 
              where p.Leader.PeopleID == 1 
              select p);

always yeilds null for object.Leader even though the association allowed for the filtering to happen correctly and the project data is all there.

even if I write the query like this..

var object = (from p in _entities.Projects 
              from pe in _entities.PeopleSet 
              where pe.PeopleID == 1 
              select p);

the result is the same

does anyone know why this happens? What am I missing?

A: 

EF 1 will never load a related type unless you force it.

I'd strongly recommend decoupling your views from entity types. Then you can force loading the correct properties (and only the correct properties) via projection:

var object = (from p in _entities.Projects 
              where p.Leader.PeopleID == 1 
              select new ViewModel
              {
                  ProjectName = p.Name,
                  LeaderName = p.Leader.Name
              });

Now the Leader info will be loaded and your view is persistence-ignorant.

Craig Stuntz
This is what I'm doing now, but it feels like a workaround. I thought that the beauty of the EF was that you'd be able use the EDM in this way without having to wrap the entities in custom classes. The views are de-coupled by the use of the repository pattern. So, it sounds like EF1 won't do what (I think) it should. Do you know if it's in the works, because it would be nice to not have to build models around the model for most of the smaller stuff. I agree, for more complex views where you don't want access to all of the properties, encapsulating a separate ViewModel class is the way to go.
Cole
You can do what you ask even in EF 1 if you use `_entities.Projects.Include("Leader")`. However, I think using persistence-ignorant views is a *better* solution.
Craig Stuntz
Ah, ok. Thanks! I'll have to read up on persistence-ignorant views.
Cole
Be careful. Much of what is written on that topic is designed for older ORMs where proxy types masquerade as POCOs. True persistence-ignorance, as exemplified with the projection example above, is different. There's nothing terribly wrong with proxies for those who understand them, but much of what people write on the subject of persistence-ignorant views presumes that you must map POCOs to have it, which is only true when you don't have projection in your ORM. It might be more helpful to read up on "presentation models," which is somewhat closer to the point here.
Craig Stuntz
A: 

Hello,

You can also do it when accessing the object:

if (!entity.Project.IsLoaded) entity.Project.Load();

As another alternative, which obviously isn't at the query level.

Brian