实体框架虚拟属性和Id属性的数据库访问？

Question

I have lot of interrelated entities in a project I'm working on, and I am using WCF to use them in several client applications. I soon realized that I was serializing half the data in the database with every call. I fixed the immediate issue but the system is still making lots of database calls, as my service layer objects iterate through all the nested objects in the data layer in their constructors. Many times this is totally unnecessary, so I started to consider alternatives.

If I specify the Id of my nested property then I don't believe the database call is made unless I access the properties of the nested object.

public class MyDataObject
{    
    public Guid Id { get; set; }
    public string SomeProperty { get; set; }
    public Guid NestedDataObjectId { get; set; }
    [ForeignKey("NestedDataObjectId")]
    public virtual NestedDataObject NestedDataObject { get; set; }
}

I can then use the constructor of my service object to determine whether to lazy load the nested objects something like this:

public class MyServiceObject
{
    public MyServiceObject(MyDataObject myDataObject, 
               bool includeNested = true)
    {
        Id = myDataObject.Id;
        SomeProperty = myDataObject.SomeProperty;
        NestedServiceObjectId = myDataObject.NestedDataObjectId;
        if (includeNested)
            NestedServiceObject = new NestedServiceObject(myDataObject.NestedDataObject,
                includeNested);
    }
}

Which works OK, except now I have an issue with my mock db context for my unit tests as I have to add the object and the id to each mock DbSet as I changed my service code to use the NestedObjectId property rather than the NestedObject.Id property

So I was wondering if the only virtual property that I accessed was the Id field if it would still make a database call for the whole of the object. Something like

if (includeNested)
{
    NestedServiceObject = new NestedServiceObject(myDataObject.NestedDataObject);
}
else
{
    NestedServiceObject = new NestedServiceObject(myDataObject.NestedDataObject.Id);
} 

This would solve my problem with my mocks, as the service code would always refer to the NestedObject.Id property and I may well end up doing this no matter what for ease of coding and maintainabilty, but I am curious as to whether or not this is the right approach.

Answer 1

The main problem here is that your service API bleeds out your data access layer. Your service model very closely reassembles your data access model and therefore it is very hard to declare what data is needed for particular method and what data can be ommited.

I would suggest to redesign your service API so that every service method accepts minimal set of input parameters and returns minimal set of output parameters.

Most likely you will have to introduce Request and Response objects for each service method. It does not mean that you can not reuse any models in different methods. You have to identify data that make sense only when used together and extract those as separate classes.

Then in every service method you can retrieve only the data that you need to create response. You can do that by defining EF data projections and mapping them to response object either manually or by using libraries like AutoMapper.

For example:

var result = db.Students
    .Select(x => new { Id = x.Id, FacultyName = x.Faculty.Name})
    .FirstOrDefault(x => x.Id == studentId);

If you write something like this, EF is actually smart enough to query only data needed.

Answer 2

When using lazy loading, EF access database when you access navigation property. When using eager loading, code will throw Null Reference exception if you try to access NestedDataObject without having loaded it first.

So I'm affraid what you are asking for is not possible.

Answer 3

你可以使用include

.Include(x => x.myDataObject.SomeProperty)