Nieprawidłowy wynik parsowania jsona

Witam. W kontrolerze mam Model:

public class MachineDetailTableRowModel
    {
        public string MachineName { get; set; }
        
        public string ConcentrationValue { get; set; }
        public string ConcentrationColor { get; set; }
        public MachineReport.eLevelState PhLevelState { get; set; }
        public string PhValue { get; set; }
        public string PhColor { get; set; }
        public MachineReport.eLevelState TrampOilLevelState { get; set; }
        public string TrampOilValue { get; set; }
        public string TrampOilColor { get; set; }
        public string CleanOutDate { get; set; }
        public bool OnlySummaryData { get; set; } = false;
        public MachineComment[] LastReportComments { get; set; }
    }
public class MachineComment
    {
        public string Date { get; set; }
        public string Comment { get; set; }
        public string CircleColor { get; set; }
    }

i akcję kontrolera zwracającą widok częściowy:

        [Authorize]
        [Route("GenerateMachineDetailTableRow")]
        public IActionResult GenerateMachineDetailTableRow(MachineDetailTableRowModel Model)
        {
            _logger.LogInformation(JsonConvert.SerializeObject(Model));
            return PartialView("ReportGenerator/_MachineDetailTableRow", Model);
        }

Skrypt js generuje następujące dane:

var data = {
                MachineName: machineData.machineName,
                ConcentrationValue: machineData.concentrationValue,
                ConcentrationColor: machineData.concentrationColor,
                PhValue: machineData.phValue,
                PhColor: machineData.phColor,
                TrampOilValue: machineData.trampOilValue,
                TrampOilColor: machineData.trampOilColor,
                CleanOutDate: machineData.cleanOutDate,
                LastReportComments: machineData.commentsFromLastReport.map(function(value, label){
                    return {
                        CircleColor: value.circleColor,
                        Comment: value.Comment,
                        Date: value.date
                    }
                }),
                OnlySummaryData: onlySummaryData,
            };
        console.log(data);
        var htmlData = $.ajax({
            url: '/ReportGenerator/GenerateMachineDetailTableRow',
            data: data,
            ...

Pole w skrypcie o nazwie poniżej jest wypełnione poprawnie, jednak po przekazaniu do modelu otrzymuję pustą tablicę. Próbowałem wyrzucić obiekt MachineComment i wstawić tablicę typu string[], z tym samym skutkiem. Gdzie może leżeć błąd? Dodam, że problem jest tylko i wyłącznie z LastReportComments

LastReportComments

Od strony Javascriptu musisz zamienić zmienną data przed wysłaniem w JSON i uzupełnić pole type / dataType.

const htmlData = $.ajax({
  type: 'post',
  url: '/ReportGenerator/GenerateMachineDetailTableRow',
  data: JSON.stringify(data),
  dataType: 'json',
  // ...
});

Zmieniłem dataType: 'json', ale bez wstawiania data: JSON.stringify(data),, ponieważ wtedy już żadna z właściwości nie pobiera wartości. problem mam tylko z niepoprawnym konwertowaniem tablicy (pierwszy raz coś takiego mi się zdarza).

Cały obiekt jest prawidłowo widoczny. Mam go w kontrolerze. Jedyne co to ta jedna właściwość. Wszystkie nazwy się zgadzają. Wygląda jakby sama tablica nie zostawała rozpoznana. To jest impossible

@_13th_Dragon: à propos tej stronki to może źle powiedziałem troszkę. Nie dysponuję jako tako jsonem. Mam obiekty tutaj, które widzę w przeglądarce w podglądzie, że są utworzone prawidłowo

LastReportComments: machineData.commentsFromLastReport.map(function(value, label){
  return {
    CircleColor: value.circleColor,
    Comment: value.Comment,
    Date: value.date
  }
}),

Po sprawdzeniu w przeglądarce mają poprawne wartości. Przy przesłaniu do kontrolera debugger pokazuje mi pustą tablicę. Co lepsze, jak spróbuje wysłać to do kontrolera jako tekst i zdeserializuję JsonConvert.Deserializeobject() to wszystkie wartości są poprawne, ale to nieeleganckie :( tak więc argumenty wysyłane do kontrolera są w 100% poprawne

A masz w Program.cs wpis żeby używać Newtonsoft.Json?

builder.Services.AddControllers().AddNewtonsoftJson();

Domyślny System.Text.Json już nie raz miał problemy z prostymi zadaniami.

AdamWox napisał(a):

A masz w Program.cs wpis żeby używać Newtonsoft.Json?

Kopiuj

builder.Services.AddControllers().AddNewtonsoftJson();

Domyślny System.Text.Json już nie raz miał problemy z prostymi zadaniami.

jakis przyklad :)?
wystarczy uzywac jak w dokumentacji

nawet jesli, to nie od razu rzym zbudowano (ewentualnie spalono) :D, jest problem, to sie zglasza issue
az mi sie przypomina jak entity framework core nie mial lazy loading bodajze =D

uzaleznianie czezsto modeli bazodanowych od zewnetrznych bibliotek (newtonsoft.json) to porazka, dlatego powinno sie przechodzic na system.text.json
nigdy nie mialem problemu z ta juz standardowo libka

heyyou napisał(a):

uzaleznianie czezsto modeli bazodanowych od zewnetrznych bibliotek (newtonsoft.json) to porazka, dlatego powinno sie przechodzic na system.text.json
nigdy nie mialem problemu z ta juz standardowo libka

Ktoś coś pisał o bazach danych? I w czym ta przewaga System.Text.Json się przejawia? Bo na pewno Newtonsoft jest rozwiązaniem dojrzalszym, bardziej sprawdzonym, bardziej elastycznym (wygodne budowanie i modyfikacja JSON), ludzie go znają i są zadowoleni (jak widać powyżej). Lepsze jest wrogiem dobrego.

tym ze czesto widuje atrybuty serializacji w encjach bazodanowych z zewnetrznej biblioteki (tu newtonsfot.json)
uzaleznienie czegokolwiek (viewmodeli, dto) od zewnetrznej libki tez jest słabe imho

btw. newtonsoftjson w performance jest o wiele slabszy z tego co kojarze ;)

za komuny tez niektorym bylo dobrze, takze ten...

heyyou napisał(a):

uzaleznianie czezsto modeli bazodanowych od zewnetrznych bibliotek (newtonsoft.json) to porazka, dlatego powinno sie przechodzic na system.text.json

Z punktu widzenia modelu (jakiegokolwiek), to System.Text.Json jest równie obcy jak Newtonsoft.Json. Jeśli MS przyznaje, że ich wersja nie wspiera wszystkiego tego, co Newtonsoft, to migracja jest ryzykowna, no chyba że liczymy na farta, że nigdy nie będziemy potrzebowali nic spoza tego kawałka, który przypadkiem zaimplementowali.

somekind napisał(a):

Jeśli MS przyznaje, że ich wersja nie wspiera wszystkiego tego, co Newtonsoft, to migracja jest ryzykowna, no chyba że liczymy na farta, że nigdy nie będziemy potrzebowali nic spoza tego kawałka, który przypadkiem zaimplementowali.

Implementacja System.Text.Json w najnowszym .necie ma już wszystko czego potrzeba i jest znacznie szybsza; jeśli czegoś nie zaimplementowano to zazwyczaj dlatego że ten feature wykraczał poza granice przyzwoitości i nie powinien istnieć - można znaleźć dużo dyskusji na githubie i dokładnych tłumaczeń czemu czegoś nie przenieśli. Jeśli polegałeś na tych "kawałkach" to zazwyczaj oznacza że gryzłeś problem od d**y strony i pora się naprostować. Jasne że deserializator może przy okazji deserializacji ugotować zupę, zrobić audyt bezpieczeństwa i przetłumaczyć tekst na japoński, ale czy to najlepsze miejsce w kodzie żeby to zrobić?

obscurity napisał(a):

Implementacja System.Text.Json w najnowszym .necie ma już wszystko czego potrzeba i jest znacznie szybsza;

Ale skąd wiesz, czego mi potrzeba?

jeśli czegoś nie zaimplementowano to zazwyczaj dlatego że ten feature wykraczał poza granice przyzwoitości i nie powinien istnieć - można znaleźć dużo dyskusji na githubie i dokładnych tłumaczeń czemu czegoś nie przenieśli. Jeśli polegałeś na tych "kawałkach" to zazwyczaj oznacza że gryzłeś problem od d**y strony i pora się naprostować.

Tak, oczywiście. Jeśli soft czegoś nie wspiera, to jest to wina użytkownika.
Pracujesz na Maku? ;)

Jasne że deserializator może przy okazji deserializacji ugotować zupę, zrobić audyt bezpieczeństwa i przetłumaczyć tekst na japoński, ale czy to najlepsze miejsce w kodzie żeby to zrobić?

Jakoś nie widzę gotowania zupy na tej liście, w ogóle nie widzę rzeczy z serializacją niezwiązanych:

źródło

Nie mówię, że System.Text.Json jest zły, żeby go nie używać, czy żeby nie migrować. Po prostu trzeba to robić z głową, będąc pewnym, że albo wspiera czego potrzebujemy OOB, albo że mamy czas na dorobienie sobie brakujących nam ficzerów.