Complex types and/or value objects

[rowanmiller]

This issue is tracking the inclusion of support for either complex types and/or value objects in EF7.x (we haven't decided what form exactly this will take or when we will do it but it is not planned for EF7.0.0 RTM).

Complex Type just means a class with no primary key - i.e. it's just a way of organizing some properties that are part of the object it is referenced from. This has been called complex types traditionally in EF.

Value objects also can be seen as a set of properties grouped under the same type that don't have a key, although there is a more formal definition and characteristics, e.g. they should be immutable, equality should be defined the values of their individual properties rather than on a key, copy value semantics is desirable.

When doing this we should consider different strategies for how the data is stored. In EF6 we had a column in the parent table for each property in the complex type. Another strategy that folks may want to chose if serializing the data as JSON/XML etc. (see #3486)

[npehrsson]

Is there a plan for when this will be implemented?

[rowanmiller]

@npehrsson no exact timeline at the moment. It's high on the backlog, close behind TPH inheritance support and navigation property translation in LINQ (which are both being implemented at the moment).

[CreepyGnome]

Will this make it into Beta 7? Beta 8? RC? If not by RC I would assume it isn't making it by RTM.

This feature has been lacking since the beginning of EF and yet has been in competitive alternatives. Without this feature EF7 will still be at a competitive disadvantage. This is a huge feature to allow people to create data models naturally for their domains without having to shoe horn them into compatible types supported by EF.

[rowanmiller]

@CreepyGnome correct, this one is triaged for post initial stable release. This would definitely fall into the bucket of features that means EF6.x will be the right choice for many apps for a while.

[CreepyGnome]

First what do you guys mean by Complex Types here?

What I mean are the ones within the .NET Framework like IDictionary, ILookup, Money, etc. I wasn't worried EF7 supporting my POCO Entities and nesting Entities within other Entities. However now I am concerned.

Technically all Domain Models are nothing but a hierarchy of Custom Complex Types that we typically like to call POCOs. I would have to say supporting custom complex types like these are mandatory for any ORM otherwise what are you mapping really? However your answer makes me think EF7 will be like EF5 and lower when it comes to any Complex Type and Nesting of them. If so that is a huge step backwards.

So are you saying EF7 doesn't support ANY complex types what so ever bet that .NET Framework or custom ones you create? If so that means EF7 doesn't supporting nesting of entities.

Also am I to assume that if it is flagged as being in the backlog, them it means no release is targeted at this time period.

[npehrsson]

I thought this was value objects, value objects = complex type in ef6, not
sure why they didn't call it value object mapping. And I agree not
supporting this is a pain for us that want to use the beta.
On Aug 25, 2015 12:36 AM, "Rodney S. Foley" notifications@github.com
wrote:

First what do you guys mean by Complex Types here?

What I mean are the ones within the .NET Framework like IDictionary,
ILookup, Money, etc. I wasn't worried EF7 supporting my POCO Entities and
nesting Entities within other Entities. However now I am concerned.

Technically all Domain Models are nothing but a hierarchy of Custom
Complex Types that we typically like to call POCOs. I would have to say
supporting custom complex types like these are mandatory for any ORM
otherwise what are you mapping really? However your answer makes me think
EF7 will be like EF5 and lower when it comes to any Complex Type and
Nesting of them. If so that is a huge step backwards.

So are you saying EF7 doesn't support ANY complex types what so ever bet
that .NET Framework or custom ones you create? If so that means EF7 doesn't
supporting nesting of entities.

Also am I to assume that if it is flagged as being in the backlog, them it
means no release is targeted at this time period.

—
Reply to this email directly or view it on GitHub
#246 (comment)
.

[rowanmiller]

Hey,

Complex Type just means a class with no primary ke - i.e. it's just a way of organizing some properties that are part of the object it is referenced from. They have historically been called "Complex Types" in EF (before my time) but I think most folks would expect a value type to be immutable (which complex types are not - though you can make the property setters private to somewhat achieve this).

Correct that this will not be in the November RC. We haven't allocated any work items to release beyond that. This is listed on our roadmap as a critical O/RM feature and something we need implemented before we start saying that EF7 is a serious alternative to EF6 for all apps.

~Rowan

[CreepyGnome]

What you described as a complex type is broad and to support that would be difficult, unless supported the way EF6 claims to support a much more limited version of Complex Types definition.

I mean a Dictionary and other core classes, don't have ID's and yet are complex types but was never supported before in EF, but is supported by others ORMs. If EF7 is only trying to be at the same level as EF6 with this feature request here, is there another feature in the backlog for support things like Dictionary<TKey, TElement>, Lookup<TKey, TElement>, HashSet, (all collections basically, Money, etc from the core .NET Framework?

[CreepyGnome]

@npehrsson Well the title is "Complex and/or value types" so they are show a clear distinction between the two. Value Type here I would assume means structs (since they already support primitives), and Complex Types would mean every other type of object that doesn't have a primary key (aka entity). However it seems that Complex Type here may mean something more limited in this feature. Since the feature has no description to clarify what its intent is, it will always be vague in what they plan to implement vs what the true definition of those words in C#.