Исключите тип из проверки модели (пример DbGeography), чтобы избежать исключения InsufficientExecutionStackException.

Я не знаю, является ли эта проблема ошибкой или ограничением веб-API, но вот мой обходной путь:

Во-первых, нам нужно создать подкласс DefaultBodyModelValidator и переопределить метод ShouldValidateType.

public class CustomBodyModelValidator : DefaultBodyModelValidator
{
    public override bool ShouldValidateType(Type type)
    {
        return type!= typeof(DbGeography) && base.ShouldValidateType(type);
    }
}

Теперь в методе Application_Start global.asax добавьте

GlobalConfiguration.Configuration.Services.Replace(typeof(IBodyModelValidator), new CustomBodyModelValidator());

и это все. Поверхностная проверка теперь будет выполняться для экземпляров типа DbGeography, и все будет хорошо связываться.

Ответ joelmdev привел меня в правильном направлении, но с моей конфигурацией WebApi в MVC и WebApi 5.2.3 новый валидатор не будет вызываться при размещении в Global.asax.

Решение состояло в том, чтобы поместить его в мой метод WebApiConfig.Register с другими маршрутами WebApi: config.Services.Replace(typeof(IBodyModelValidator), new CustomBodyModelValidator());

Просто была точно такая же проблема, но затем с пользовательским типом. После довольно большого исследования это оказалось вполне логичным со знанием этой темы. Пользовательский класс имел общедоступное свойство только для чтения, которое возвращало другой экземпляр того же класса. Валидатор просматривает все свойства класса (даже если вы вообще не выполняете проверку) и получает значение. Если ваш класс возвращает новый экземпляр того же класса, это происходит снова и снова и... Похоже, что свойство StartPoint в классе Geography имеет ту же самую проблему. https://msdn.microsoft.com/en-us/library/system.data.spatial.dbgeography.startpoint(v=vs.110).aspx

Если у вас возникла такая же проблема с приложением Mvc, вам может быть интересен этот ответ. Это подойдет не всем, но, поскольку меня интересовали исключительно широта и долгота, мое окончательное решение этой проблемы состояло не в игнорировании свойств DbGeography, а в том, чтобы проинструктировать компоновщик модели, как правильно их проверять или, по крайней мере, как я хотел. подтверждено. Этот подход позволяет работать стандартным свойствам атрибутов проверки и позволяет мне использовать обычные элементы управления Html для широты и долготы. Я проверяю их как пару, так как в конечном итоге они привязаны к одному свойству DbGepgraphy в вашем классе модели, поэтому одного из них недостаточно, чтобы считаться действительным. Кроме того, я думаю, что для этого требуется ссылка на пакет Microsoft.SqlServer.Types Nuget, который соответствует используемой целевой версии SQL Server, но вы, вероятно, уже ссылаетесь на него.

using System;
using System.Data.Entity.Spatial;
using System.Web.Mvc;

...

public class CustomModelBinder : DefaultModelBinder
{
    public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var latitudePropertyValue = bindingContext.ValueProvider.GetValue(string.Concat(bindingContext.ModelName, ".", nameof(DbGeography.Latitude)));
        var longitudePropertyValue = bindingContext.ValueProvider.GetValue(string.Concat(bindingContext.ModelName, ".", nameof(DbGeography.Longitude)));

        if (!string.IsNullOrEmpty(latitudePropertyValue?.AttemptedValue)
            && !string.IsNullOrEmpty(longitudePropertyValue?.AttemptedValue))
        {
            if (decimal.TryParse(latitudePropertyValue.AttemptedValue, out decimal latitude)
                && decimal.TryParse(longitudePropertyValue.AttemptedValue, out decimal longitude))
            {
                // This is not a typo - longitude does come before latitude here
                return DbGeography.FromText($"POINT ({longitude} {latitude})", DbGeography.DefaultCoordinateSystemId);
            }
        }

        return null;
    }
}

Затем пользовательский провайдер, который его использует:

using System;
using System.Data.Entity.Spatial;
using System.Web.Mvc;

...

public class CustomModelBinderProvider : IModelBinderProvider
{
    public IModelBinder GetBinder(Type modelType)
    {
        if (modelType == typeof(DbGeography))
        {
            return new CustomModelBinder();
        }

        return null;
    }
}

Затем в Application_Start() в Global.asax.cs:

ModelBinderProviders.BinderProviders.Add(new CustomModelBinderProvider());

Затем в моей модели это позволяет мне просто использовать обычный RequiredAttribute:

[Display(Name = "Location")]
[Required(ErrorMessage = "You must specify a location")]
public DbGeography Location { get; set; }

И, наконец, чтобы использовать это в представлении, я создал шаблоны отображения и редактора. В ~/Views/Shared/DisplayTemplates/DbGeography.cshtml:

@model System.Data.Entity.Spatial.DbGeography
@Html.LabelFor(m => m.Latitude), 
@Html.LabelFor(m => m.Longitude)

В ~/Views/Shared/EditorTemplates/DbGeography.cshtml:

@model System.Data.Entity.Spatial.DbGeography
@Html.TextBoxFor(m => m.Latitude), 
@Html.TextBoxFor(m => m.Longitude)

И затем я могу использовать этот шаблон редактора в любом другом обычном представлении, например:

@Html.LabelFor(m => m.Location)
@Html.EditorFor(m => m.Location)
@Html.ValidationMessageFor(m => m.Location, "", new { @class = "error-message" })

Вы также можете использовать скрытые поля в своем представлении редактора и добавить немного JavaScript в свой шаблон, например, для создания карты Google, при условии, что скрипт карты также снова устанавливает значения скрытых полей при выборе координаты.

Если у вас возникла эта проблема в WebAPI 5.2.3, единственный способ исправить это, который сработал для меня, — это использовать вариант метода, который я описал здесь: https://stackoverflow.com/a/40534310/2001934

В основном я использовал настраиваемый обязательный атрибут для свойств DbGeography в своих моделях, который в MVC будет работать полностью как обычный обязательный атрибут, но в WebApi я добавил дополнительный адаптер атрибута, который всегда заменяет список проверки клиента. rules с новым пустым списком, чтобы в привязке модели WebApi для тех же свойств не выполнялась проверка.

В этом ответе не хватало только того, как заменить существующий ModelValidatorProvider в WebApi:

DataAnnotationsModelValidationFactory factory = (p, a) => new DataAnnotationsModelValidator(
    new List<ModelValidatorProvider>(), new CustomRequiredAttribute()
);

DataAnnotationsModelValidatorProvider provider = new DataAnnotationsModelValidatorProvider();
provider.RegisterAdapterFactory(typeof(CustomRequiredAttribute), factory);

GlobalConfiguration.Configuration.Services.Replace(typeof(ModelValidatorProvider), provider);