DTO和实体框架

Question

My solution uses Entity Framework, and I translate the EF models to DTO objects to pass up and down from the UI layer.

But I have a design question: I have a Person table, and a PersonUnavailibility table. A person can have period where they are unavailable.

My PersonDTO object has all the properties of the PersonEF model, as well as a List<PersonUnavailibilityDTO> objects. So, when I get my person, I also get the persons periods of unavailibility.

However, should my PersonUnavailibilityDTO have a PersonDTO object? So if I get a PersonUnavailibilityDTO object, I can see which person it's related to?

If so, I get a circular references. My PersonUnavailibilityDTO's Person property, has a list of all his PersonUnavailibility rows... and each of those, has a PersonDTO , and each of those has a list of.... etc etc.

What is the best design for this sort of thing? Only include child objects related to the parent object?

That is, only the PersonDTO has a list of PersonUnavailibilityDTOs , but the PersonUnavailibilityDTO doesn't have a PersonDTO ?

Answer 1

It depends.

In most cases it would not be required since you will be viewing the dto's from the persons view and the unavailabilities are always accessed through the person.

But when you will access your object the other way around it is nescessary to add the person to the unavailability.

Try to keep your Dto's as small and minimalistic as possible.

Answer 2

One of possible approaches would be to have a generic composite dto model to carry all possible combinations of entities.

http://netpl.blogspot.com/2010/12/generic-dto-model-and-other-silverlight.html

At the price of losing the strict structure, you get a reusable one.

Answer 3

As a general recommendation, it's better to avoid bidirectional relationships between objects.

The risk is to have objects that are out of sync, ie object A points to B (or a collection of B) but B doesn't point to A - typically, it will have a null reference instead. To prevent that from happening, you always have to keep both ends of the relationship synchronized, which comes at a cost.

However, this point is mitigated when the objects are immutable (which may be the case with your DTO's) since they are composed at creation and never modified afterwards, nullifying the risk of discrepancy between them.

As Jeroen pointed out, I'd still recommend going for the simplest possible solution : PersonDTO -> PersonUnavailibilityDTO until definitely proven that you need the reverse relationship.

Answer 4

I prefer removing collections from DTOs and adding service methods to request the collections instead:

function GetUnavailable(PersonID, Options) as IEnumerable(of PersonUnavailabilityDTO)

This way

1. No circular references

2. DTO tends to be light weight

3. The actual collection can be neatly specified with additional filters, ordering or paging applied directly in database