Breeze js AutoGeneratedKeyType винаги е „няма“ с ODataConventionModelBuilder

Имам прост poco обект на entityframework

public partial class Location: Entity
{
    [Key]
    public int Id { get; set; }
    public string Description { get; set; }
}

Обектът baseClass изглежда както следва

public abstract class Entity : IObjectState
{
    [NotMapped]
    public ObjectState ObjectState { get; set; }
}

Излагам този обект чрез услуга Odata, използвайки ODataConventionModelBuilder

        var server = GlobalConfiguration.DefaultServer;
        ODataModelBuilder builder = new ODataConventionModelBuilder();
        builder.Namespace = "MyNameSpace.Models";
        builder.EntitySet<Location>(typeof(Location).Name);
        var model = builder.GetEdmModel();
        config.Routes.MapODataServiceRoute("odata", "odata", model, new DefaultODataBatchHandler(server));


        config.AddODataQueryFilter();

Когато използвам тази услуга с Breeze js, получавам грешка от breeze, когато се опитвам да създам обект с manager.CreateEntity().

Не може да се прикачи обект към EntityManager, без първо да се зададе неговия ключ или да се зададе свойството му entityType „AutoGeneratedKeyType“ на нещо различно от „Няма“

Когато направя заявка за обект и редактирам данните и ги запазя. Всичко е наред.

Използвам angular в комбинация с breeze на клиента и Asp.net webapi 2 в комбинация с odatacontroller на сървъра с EntityFramework 6 като ORM.

Може ли някой да ми каже какво правя грешно!!!


javascript angularjs entity-framework odata breeze
person Gabe    schedule 21.08.2014    source източник

Отговори (1)


arrow_upward
2
arrow_downward

ODataConventionModelBuilder на Microsoft е много непълен и те са наясно с това (Това се отнася както за OData WebApi v 2.1, така и за v 2.2). Заедно с редица по-малки проблеми, той не поддържа „referentialConstraints“ или каквато и да е информация за генерираните от магазина ключове. MS е наясно с тези проблеми, наред с други, и каза, че някои от тях ще бъдат коригирани в нова версия някъде през октомври.

Дотогава имате няколко възможности.

  • Използвайте ODataConventionBuilder, но след това актуализирайте metadataStore на breeze, след като метаданните бъдат извлечени, за да „коригирате“ липсващите или грешни метаданни.

    myMetadataStore.metadataFetched.subscribe(function(args) {
  var ms = args.metadataStore;
  var entityType = ms.getEntityType("Customer");
  entityType.setProperties({ autoGeneratedKeyType: AutoGeneratedKeyType.Identity });
  dp = entityType.getDataProperty("companyName");
  dp.validators.push(Validator.maxLength({ maxLength: 40 }));
  // etc... 
});

  • Избягвайте изобщо да извличате метаданни от сървъра и просто опишете метаданните директно на breeze клиента: (вижте: http://www.breezejs.com/documentation/metadata-by-hand)

  • Пропуснете напълно OData и използвайте внедряването на Breeze WebApi (вижте http://www.breezejs.com/documentation/aspnet-web-api). Това има предимството да бъде както най-пълното, така и най-стабилното изпълнение на всички функции на Breeze. Повечето от примерите на Entity Framework в breeze.js.samples са изградени с това.

Като цяло, ние НАИСТИНА препоръчваме последния избор, ако е достъпен за вас. Моля, прочетете това (http://www.breezejs.com/documentation/odata-server ) за повече информация.

person Jay Traband    schedule 21.08.2014
comment
Обмислих последните опции, но нещото с последната опция е, че намирам за много неестествено прилагането на бизнес логика и модели на програмиране по този начин. Може би можете да ме насочите към пример, където последната опция се използва в комбинация с модела UnitofWork и модела на хранилището - person Gabe; 22.08.2014
comment
Не съм сигурен, че разбирам, API от страна на сървъра и за двете могат да бъдат идентични. ЕДИНСТВЕНАТА разлика може да бъде основното използване на WebApi. - person Jay Traband; 22.08.2014
comment
Това, което имам предвид, е, че трябва да използвам едно от събитията преди запазване на EFContextProvider, вместо да записвам нещата, когато искам и в реда, в който искам. това ми се струва малко неестествено. - person Gabe; 25.08.2014
comment
Всъщност, ако погледнете примера на NoDb в репото Breeze.js.samples, МОЖЕТЕ напълно да поемете операцията за постоянство, ако искате, но това е много повече работа. И.. ако използвате EF и поддържате графика от обекти, тогава EF е този, който нарежда вашето запазване, а не Breeze. - person Jay Traband; 25.08.2014