Generic EntityReference

[dotfede]

@MattB-msft I've given you access to our (private by now) CDS library. I intend to make this public at some point, but we're going thru some internal stuff that needs to get resolved first, and I would like to add documentation to the project too.

That said, if you look here you'll see that I created a generic version of EntityReference. This works great and greatly improves type safety, since, for example, an EntityReference<Account> is NOT the same as an EntityReference<Contact>, therefore we get compile time safety to not mistakenly assign one another.

Unfortunately, the CDS LINQ provider does not "know" my class at all, and therefore is unable to resolve queries like this:

EntityReference<Contact> contactId = GetMyContactId();

var accounts = 
    CrmService.Query<Account>()
              .Where(x => x.PrimaryContactId == contactId)
              .ToList();

Since it attempts to serialize contactId and I get a WCF error saying that's not a known type.

I would be awesome if it was supported, so I propose 2 things here:

• 1 Please include a generic version of EntityReference in the first party SDKs
• 2 Add a way to extend the LINQ provider in such a way that these cases can be supported by third parties. NHibernate for example does this. It has extensibility points built in for it's own LINQ provider.

[mathiasbl]

A generic version of EntityReference won't work since there are lookup fields in CDS that can point to more than 1 entity. Think about the customer or regarding lookups.
At compile time you don't know to which entity it will refer.

As for the LINQ provider. You can write your own QueryProvider around the CDS Linq provider which translates your expression (with your custom object) to a expression that the CDS linq provider can understand.

[dotfede]

@mathiasbl

A generic version of EntityReference won't work since there are lookup fields in CDS that can point to more than 1 entity. Think about the customer or regarding lookups.
At compile time you don't know to which entity it will refer.

I disagree. This would improve 95+ percent of the cases, where entity references target a single entity. 100% of the custom entities for starters.

For the cases where you have exactly 2 (Customer) target entities, I can imagine an EntityReference<A,B> to deal with that.

Also, for the remaining 5% where you can't determine the entity type up front (because it's dynamic, such as Annotation.RegardingObjectId, just keep the regular untyped EntityReference. I already did this and I'm running code in production right now which uses the EntityReference<T>. The change from untyped to typed was totally tranparent after I modified my early bound generator. Except for 1 case where by mistake an EntityReference<A> was being assigned an EntityReference<B>, which resulted in a compile error, rather than a runtime exception.

As for the LINQ provider. You can write your own QueryProvider around the CDS Linq provider which translates your expression (with your custom object) to a expression that the CDS linq provider can understand.

I didn't know this. Is there any sample code to use as a starting point? OrganizationServiceContext doesn't seem to have any configurable properties that I can use to tell it to use my custom LINQ provider.

[dotfede]

@mathiasbl For the record:

I just performed a Find All References of both EntityReference and EntityReference<T> in my largest project's model code. I found this:

• 356 usages of EntityReference<T>
• 31 usages of EntityReference.

Which confirms my ~90%-10% claim.

[dotfede]

I didn't know this. Is there any sample code to use as a starting point? OrganizationServiceContext doesn't seem to have any configurable properties that I can use to tell it to use my custom LINQ provider.

On a second thought, I could simply wrap OrganizationServiceContext in my own abstraction and call it after having resolved the custom logic. For example replacing x => x.MyEntityRef == value with x => x.MyEntityRef.Id == value.Id and so on.

[mathiasbl]

From Microsoft's perspective you'd want a solution which fits 100% of the time. Which is what EntityReference brings today.

I can agree you might want more fool proof code but imo this shouldn't be part of the SDK.

As for the QueryProvider. We created an extension on IQueryable (I know it's not ideal but the EntitySets are IQueryables) which just returns a custom IQuerable implementation which has some additional logic.

        public static ID365Query<TSource> AsD365Query<TSource>(this IQueryable<TSource> queryable) where TSource : Entity
        {
            return new D365Query<TSource>(queryable);
        }

[sergeytunnik]

Kind of off-topic, but EntityReference also lacks value object properties. It is a class (not struct), but there is no override for equals operator (==).

var efLeft = new EntityReference("account", Guid.Empty);
var efRight = new EntityReference("account", Guid.Empty);
var areEqual = efLeft == efRight;

areEqual is false, which is not any D365 developer would want in 99% cases. Same true for Money type. Taking in mind that any of them might be null simple equality check becomes a monster.

var areEqual2 = efLeft?.LogicalName == efRight?.LogicalName && efLeft?.Id == efRight?.Id;

It might get worse without null conditional operator.

Is there any chance this could be addressed in the future?
I can create separate issues for this and fire PR with changes.

[MattB-msft]

@fberasategui regarding what your doing with a typecase entityreferance, given that you extended the object, you could add a ISerializable and look at implementing the interfaces there to custom serialized the object back into a normal entity refence. This is similar to how we do a number of things in the wire transport for talking to CDS. Have you explored that?

@sergeytunnik, that is something we have discussed a few times for several of our classes.
We have discussed it as part of core or we could add it as a extension in the client libs.

The tradeoff's are that the utility would be diminished if we only added it in the client libs.
I will pass your thoughts on to to the team to add to the discussion.

[dotfede]

@MattB-msft thanks for the suggestion. One thing though: my class does not inherit from EntityReference, because that class is sealed