Support unidirectional many-to-many relationships

[dealdiane]

Support shadow navigation properties such that views over the navigations can function even when a CLR type doesn't have an actual navigation property. This would enable unidirectional many-to-many relationships like this:

class Post
{
  public int Id { get; set; }
  public ICollection<Tag> Tags { get; set; }
}

class Tag
{
  public int Id { get; set; }
}

builder.Entity<Post>()
  .HasMany(p => p.Tags)
  .WithMany();

---

Original issue:

Are there any plans to support this?

table.Include(t => EF.Property<Entity>(t, "Property"))

[divega]

No plans for EF Core RTM.

We are going to enable unbound navigation properties only in metadata so that they can be used in the model snapshot for Migrations (see #2140) but we plan to block their use in runtime scenarios.

Anyway, in case we decide to enable this feature in the future. Could you explain how you expect it to work and how you would take advantage of it?

[dealdiane]

TL;DR I'm closing this as it might be only beneficial for a very specific use-case and by using extension methods and casting, I got it to work in the end without hurting performance (I hope).

---

The only reason why someone might find this beneficial is if they're using a generic repository pattern.

Suppose I have these DTOs in my "Core" project without a reference to EF Core.

public class Product
{
    public int Id { get; set; }

    public IEnumerable<string> Keywords { get; set; }
}

public class Review
{
    public int Id { get; set; }

    public Product Product { get; set; }
}

.. and these DTOs are from a separate project with a reference to EF Core. They inherit from the Core DTOs. You could argue that Keywords should've been kept in a separate table and I think you're right but I'm working with an existing database here so I don't have the flexibility of defining my own schema.

public class EFProduct
{
    public int Id { get; set; }

    public string KeywordsCombined 
    { 
        get
        {
            return String.Join(",", Keywords);
        }

        set
        {
            Keywords = value?.Split(",");
        }
    }
}

public class EfReview
{
    public EFProduct EFProduct
    {
        get
        {
            return Product as EFProduct;
        }
        set
        {
            Product = value;
        }
    }
}

I would configure my DBContext like so,

modelBuilder.Entity<EfProduct>()
    .Ignore(p => p.Keywords);

modelBuilder.Ignore<Review>();

modelBuilder.Entity<EfReview>
    .Ignore(r => r.Product)
    .HasOne(r => r.EFProduct)
    .WithMany()
    .HasForeignKey(r => r.ProductId);

Here's my generic repository interface:

public interface IRepository<TEntity> : IQueryable<TEntity>
{
     // IQueryable members here
     // CRUD members here
}

and the EF implementation of that interface:

public class EFRepository<TEntity> : IRepository<TEntity>
{
    public EntityFrameworkRepository(DbContext db)
    {
        Table = _db.Set<TEntity>();
    }

    public Type ElementType
    {
        get
        {
            return Table.ElementType;
        }
    }

    public Expression Expression
    {
        get
        {
            return Table.Expression;
        }
    }

    public IQueryProvider Provider
    {
        get
        {
            return Table.Provider;
        }
    }

    public virtual DbSet<TEntity> Table
    {
        get;
        private set;
    }
}

This is where I would find this helpful:

Suppose I have this interface in my core as well:

public interface IProductService
{
    IAsyncEnumerable<Review> GetReviews();
}

and my implementation from the class that has a reference to EF Core:

public class ProductService
{
    private readonly IRepostitory<Review> _reviews;

    public ProductService(IRepostitory<Review> reviews)
    {
        _reviews = review;
    }

    public IAsyncEnumerable<Review> GetReviews()
    {
        return _reviews
            .Include(r => EF.Property<Product>(r, "EFProduct"))
            .AsAsyncEnumerable();
    }
}

Since in my ProductService I am taking an instance of IRepository<Review> not IRepository<EFReview>, I would not have access to the EFProduct property. You might ask, "why not take a dependency on IRepository<EFReview> instead?". Well, yes, If I could I will but the project that ties everything together (a website in this case) do not know anything about EF at all which means it doesn't know EFReview. All it knows, is that I have an IProductService that takes an IRepository<Review> dependency (only the types from my Core project).

All this crazy abstraction is so that we can swap out different implementations of different services as we move multi-platform on our project.

[divega]

Thanks. From the description I understand that your scenario is that you want to apply a very specific workaround to a limitation of EF (ideally you should be able to map the Keywords property) while keeping layers above the repository persistence agnostic.

I believe there are other scenarios in which not having a navigation property in the CLR type but still being able to refer to it in LINQ queries could be more generally useful, so I will reopen the issue for triage.

[dealdiane]

From the description I understand that your scenario is that you want to apply a very specific workaround to a limitation of EF (ideally you should be able to map the Keywords property) while keeping layers above the repository persistence agnostic.

I think you might be referring to the EFProduct property in the EFReview class. Actually, it's a workaround another limitation of EF. If EF could map the EFReview.Product to an EFProduct class then there is no need for the EFReview class - let me know if EF can do this, I might've just missed it. In my example, the EFReview class is only there as a wrapper so that the navigation property Product would work.

I believe there are other scenarios in which not having a navigation property in the CLR type but still being able to refer to it in LINQ queries could be more generally useful

I'm pretty sure there is and this would probably be especially useful when abstracting things although I could not think of anything at the moment except what I've given so far.

[Deilan]

Any updates on the subject?

[rowanmiller]

Not yet. We have higher priority features on the backlog, so this won't be in the first round of features we pick to implement.

[HappyNomad]

Once #1368 (comment) and #8881 are both implemented then, given (1) a many-to-many relationship between Product and Org and (2) a many-to-many shadow navigation property PurchasedBy of type IList<Org>, I'll need to write:

modelBuilder.Entity<ProductDetail>().HasQueryFilter( d => d.Product.PurchasedBy.Any( o => o.ID == TenantID ) );

So I need to tack the PurchasedBy shadow property onto d.Product. Will the following work?

modelBuilder.Entity<ProductDetail>().HasQueryFilter( d => EF.Property<IEnumerable<Org>>( d, "Product.PurchasedBy" ).Any( o => o.ID == TenantID ) );

If support for this syntax isn't yet planned, then please address this issue (or #6412 but it's closed.) to enable this scenario.