2

В настоящее время у меня есть сущность, которая «геолокатируется» через столбец SqlGeography, который я могу использовать с помощью выражений для фильтрации и сортировки. Я уже могу получить все объекты на расстоянии x точки y и сортировать по объектам, ближайшим к (или дальше от) точке y. Однако, чтобы вернуть расстояние от объекта до y Мне нужно пересчитать расстояние в приложении, потому что я еще не определил, как материализовать результат вычисления расстояния от базы данных до объектов в IQueryable. Это сопоставленная сущность, и большая часть логики приложения окружает тип возвращаемой сущности, поэтому проектирование его в динамический объект не является жизнеспособным вариантом для этой реализации (хотя я понимаю, как это будет работать). Я также попытался использовать unmapped объект, который наследуется от сопоставленного объекта, но он испытывает те же проблемы. По сути, насколько я понимаю, я должен был бы определить получателя немаркированного свойства, чтобы назначить вычисленное значение в запрашиваемом расширении. ЕСЛИ я изменяю дерево выражений, которое представляет IQueryable, но то, как это ускользает от меня. Ранее я писал выражения таким образом, но я думаю, что мне нужно изменить существующий выбор, а не просто цепочки на новом Expression.Call, который для меня не изучен.Как вернуть DbGeography.Distance рассчитанное значение в Code First Entity Framework без потери сильной печати?

Ниже следует код должен правильно проиллюстрировать эту проблему:

using System; 
using System.Collections.Generic; 
using System.ComponentModel.DataAnnotations; 
using System.ComponentModel.DataAnnotations.Schema; 
using System.Data.Entity; 
using System.Data.Entity.ModelConfiguration; 
using System.Data.Entity.Spatial; // from Microsoft.SqlServer.Types (Spatial) NuGet package 
using System.Linq; 

public class LocatableFoo 
{ 
    [Key] 
    public int Id { get; set; } 

    public DbGeography Geolocation { get; set; } 

    [NotMapped] 
    public double? Distance { get; set; } 
} 

public class PseudoLocatableFoo : LocatableFoo 
{ 
} 

public class LocatableFooConfiguration : EntityTypeConfiguration<LocatableFoo> 
{ 
    public LocatableFooConfiguration() 
    { 
     this.Property(foo => foo.Id).HasColumnName("id"); 
     this.Property(foo => foo.Geolocation).HasColumnName("geolocation"); 
    } 
} 

public class ProblemContext : DbContext 
{ 
    public DbSet<LocatableFoo> LocatableFoos { get; set; } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     modelBuilder.Configurations.Add(new LocatableFooConfiguration()); 

     base.OnModelCreating(modelBuilder); 
    } 
} 

public class Controller 
{ 
    public Controller(ProblemContext context) // dependency injection 
    { 
     this.Context = context; 
    } 

    private ProblemContext Context { get; set; } 

    /* PROBLEM IN THIS METHOD: 
    * Do not materialize results (ie ToList) and then calculate distance as is done currently <- double calculation of distance in DB and App I am trying to solve 
    * Must occur prior to materialization 
    * Must be assignable to "query" that is to type IQueryable<LocatableFoo> 
    */ 
    public IEnumerable<LocatableFoo> GetFoos(decimal latitude, decimal longitude, double distanceLimit) 
    { 
     var point = DbGeography.FromText(string.Format("Point({0} {1})", longitude, latitude), 4326); // NOTE! This expects long, lat rather than lat, long. 
     var query = this.Context.LocatableFoos.AsQueryable(); 

     // apply filtering and sorting as proof that EF can turn this into SQL 
     query = query.Where(foo => foo.Geolocation.Distance(point) < distanceLimit); 
     query = query.OrderBy(foo => foo.Geolocation.Distance(point)); 

     //// this isn't allowed because EF doesn't allow projecting to mapped entity 
     //query = query.Select(foo => new LocatableFoo { Id = foo.Id, Geolocation = foo.Geolocation, Distance = foo.Geolocation.Distance(point) }); 

     //// this isn't allowed because EF doesn't allow projecting to mapped entity and PseudoLocatableFoo is considered mapped since it inherits from LocatableFoo 
     //query = query.Select(foo => new PseudoLocatableFoo { Id = foo.Id, Geolocation = foo.Geolocation, Distance = foo.Geolocation.Distance(point) }); 

     //// this isn't allowed because we must be able to continue to assign to query, type must remain IQueryable<LocatableFoo> 
     //query = query.Select(foo => new { Id = foo.Id, Geolocation = foo.Geolocation, Distance = foo.Geolocation.Distance(point) }); 

     // this is what I though might work 
     query = query.SelectWithDistance(point); 

     this.Bar(query); 
     var results = query.ToList(); // run generated SQL 
     foreach (var result in results) //problematic duplicated calculation 
     { 
      result.Distance = result.Geolocation.Distance(point); 
     } 

     return results; 
    } 

    // fake method representing lots of app logic that relies on knowing the type of IQueryable<T> 
    private IQueryable<T> Bar<T>(IQueryable<T> foos) 
    { 
     if (typeof(T) == typeof(LocatableFoo)) 
     { 
      return foos; 
     } 

     throw new ArgumentOutOfRangeException("foos"); 
    } 
} 

public static class QueryableExtensions 
{ 
    public static IQueryable<T> SelectWithDistance<T>(this IQueryable<T> queryable, DbGeography pointToCalculateDistanceFrom) 
    { 
     /* WHAT DO? 
     * I'm pretty sure I could do some fanciness with Expression.Assign but I'm not sure 
     * What to get the entity with "distance" set 
     */ 
     return queryable; 
    } 
} 
+0

Извините, здесь не много справки, но когда у вас есть код, который выполняет проверку типа для общего параметра в универсальном методе, это должно немедленно поднять сигналы тревоги в вашей голове. –

+0

@JeffMercado, метод Bar() действительно предназначен только для инкапсуляции требования о том, что логика, зависящая от типа, будет выполняться на IQueryable. Это не свидетельствует о реальной логике приложения, так как область моей проблемы намного сложнее. В принципе, вы можете предположить, что Bar() не является репрезентативным для реальной логики на практике, просто абстрактно. На практике то, что я сократил до LocalizableFoo, является одним из нескольких сущностей, которые реализуют интерфейсы (или не работают) в зависимости от того, как они должны вести себя в конвейере композиции запроса. –

+0

Так ваш метод «Бар» должен иметь доступ к вашему поле «Расстояние»? Вы беспокоитесь, что перерасчет расстояния в приложении дорого? Это правда? Или это просто «уродливо»? – MBoros

ответ

0

Поле Distance логически не является частью вашего table, так как он представляет собой расстояние до динамически определенного d точка. Таким образом, он не должен быть частью вашей организации.

В этот момент, если вы хотите, чтобы он был рассчитан на db, вы должны создать хранимую процедуру или TVF (или sg else), которая возвращает вашу сущность, расширенную с расстоянием. Таким образом вы можете сопоставить возвращаемый тип с Entity. Это более ясный дизайн для меня кстати.

+0

Мы использовали этот такт в других местах, но расстояние очень похоже на «рассчитанную» колонку для меня. Я надеялся, что выражение может быть изменено непосредственно для поддержки '[DbGeneratedColumn]', но его кажущееся все более и более маловероятно. В этом случае я просто отмечу это как ответ и рассмотрю множество ТВФ для доступа к ароматам 'Foo'. –

1

насчет замены линии

var results = query.ToList(); 

с

var results = query 
       .Select(x => new {Item = x, Distance = x.Geolocation.Distance(point)} 
       .AsEnumerable() // now you just switch to app execution 
       .Select(x => 
       { 
        x.Item.Distance = x.Distance; // you don't need to calculate, this should be cheap 
        return x.Item; 
       }) 
       .ToList(); 
+0

Это в основном аромат динамической проекции, который, как я сказал в вопросе, я понимаю, как это сделать, но не могу использовать. Мне нужно выбрать вычисляемый столбец для сопоставленного объекта, не проецируя его на динамический, поскольку весь конвейер запросов построен на понятии композитивности, и если я должен перечислить тип, отличный от 'IQueryable ', где 'T' - моя сопоставленная сущность , тогда композиция сломается. Его очень похоже на свободный синтаксис, когда каждый метод должен возвращать тот же тип, что и тип объекта, на котором он действует. –

+0

Идея здесь заключалась в том, что вы выполняете проекцию только после вызова всех методов, которые набраны. Вот почему я спросил вас, нужен ли метод «Бар» для вашего поля «Расстояние»? Я предположил, что нет, но теперь я думаю, что это не так. – MBoros