Shadow property support

[rofenix2]

Hi, this doesnt seems to work:

x.Descending(x => EF.Property<DateTime>(x, "CreateDate"));

Any support for shadow properties or work around?.

The reason we cant just use the property directly its cause we mix entities and domain types, we hide specific entities properties like creation date, update date and others with shadow properties and expose only domain properties. Until now EF Core support for this is great, but testing this library (which ive been using for some time) i found out shadow properties are not supported or at least i cant find a way.

Thanks.

[mrahhal]

Hi. Yes right now it's not possible. I would definitely like to support this use case if I can. I'll try to investigate soon.

[mrahhal]

I can foresee a problem related to how the keyset is formed from the reference. This library doesn't enforce using the same model type for the reference you provide, this it to allow any kind of loose object (for example, a dto) to be used as a reference, as long as it contains all properties matching the keyset.

So we're unopinionated about the type of the reference, which means it might be hard to properly get a shadow property from the reference to form the keyset. It could be the model type, which means we would have to somehow access the db context to obtain the shadow prop value. This isn't good nor feasible. And it could be another type, which means you would have to manually set a property on it that corresponds to the shadow property.

So it seems for shadow support, I might have to require a non model type reference so that you can set an explicit property on it. Not sure if I like this either.

[rofenix2]

The problem seems to be Microsoft is pushing the idea of using the same model where domain objects are fused with entities for agile development. For example their eShopOnContainers repository for Microservices uses this model and tho i am unaware of the design decisions behind EFCore everything points to me that shadow properties, backing fields and navigation using those private backing fields where made with that intention as well.

Also ive gone with the route of splitting domain businesss objects and entities and its really a pain mapping back and forth between layers, also you have to fix the identity resolution in this route when you want to re use the domain object or find the cached entity and update it with the new data which is a real pain. This is all fixed with using the same model and so far ive been modeling complex business objects without ever having the need to implement something so difficult that needs to be in its own entity.

So while i agree this library doesnt enforce using the same model type, it does seems to be direction Microsoft and EFCore team is pushing or at least they are giving a lot of support for devs like to me go that route and this library maybe could go that route as well.

[mrahhal]

It has always been the case that an entity and a domain model is one and the same in EF. You could do your designs around them if you want to split them but as you said it'll be painful. A better option in this context is to just treat domain models as the db objects and then create DTOs if you want to hide or transform things in the response. So instead of hiding things in the domain model using shadow properties, you'd create DTOs that don't include these properties.

But this is a completely seperate problem in any case. So for now, I don't think shadow properties can be supported in the keyset in this library in a way that would make sense.