Сообщение Re[5]: .NET ненависти псто от 30.09.2024 9:10
Изменено 30.09.2024 9:17 Doom100500
Re[5]: .NET ненависти псто
Здравствуйте, Михаил Романов, Вы писали:
D>>Если клиент использует SystemTextJsonFormatter, то параметры не сериализуются. А с JsonMessageFormatter — нет проблем.
МР>А какое поведение вы ожидаете?
Хотелось бы, чтобы заявленное поведение всё-таки присутсввовало независимо от используемого паерсера. В данном случае — это ядро библиотеки, которая не разобралась со своими — же обёртками над своим — же парсером.
МР>XXXFormater Это же просто обертка над разными сериализаторами.
МР>Эти 2 сериализатора сделаны разными людьми, используют разную разметку атрибутами и работают местами по-разному. Есть даже довольно большая статья в MSDN по миграции с одного на другой Migrate from Newtonsoft.Json to System.Text.Json — там явно не всё, но даже этого — выше крыши.
Да, я всё это читал, но через интерфейсы этих обёрток всё равно не пробиться к парсеру напрямую, кроме как самому всё разгребать — т.е. переписать ядро библиотеки — т.е. нафейфуа она тогда мне вообще? Ни перегрузок, чтобы переопределять поведение, ни свойств. Просто бери — копируй код и меняй потроха. Не таким я себе представлял Open Source.
МР>Ну а то, что ребята не стали завязываться на какой-то один сериализатор, а сделали возможность использовать тот, который вам удобнее — это же наоборот отлично!
Только сторонний работает по своей-же документации, а свой — нет. Просто молодцы, чё!
МР>Вы просто выберите какой-то один, который вам подходит больше и остановитесь на нем.
Поведение разное, несмотря на то, сама спецификация JsonRpc — на полторы страницы в хроме. Какая разница какой парсер? Есть метод, есть параметры, есть результат — работай (атрибуты — это, действительно, fine tunning, опустим их)
D>>Ничего, кроме негатива, не испытал исследуя эту либу (официальную от Майков!!!)
МР>Ну если весь негатив сводится к различию в поведении JSON-сериализаторов, которые являются внешними по отношению к этой библиотеке, то для меня библиотека выглядит вполне приличной.
Плюс кастомизация, переопределение поведения (см. выше).
Да и поведение не надо быбло бы менять, если бы с парсерами проблем не было бы таких диких.
МР>Я, откровенно говоря, не помню, чтобы где-то в документации или статьях на неё особо ссылались. Даже та же gRPC встречается куда чаще.
Нужен протокол JsonРpc, не Grpc. И эта либа единственная от microsoft (мы не хотим стороннего из — за бюрократии, но это другая проблема).
D>>Если клиент использует SystemTextJsonFormatter, то параметры не сериализуются. А с JsonMessageFormatter — нет проблем.
МР>А какое поведение вы ожидаете?
Хотелось бы, чтобы заявленное поведение всё-таки присутсввовало независимо от используемого паерсера. В данном случае — это ядро библиотеки, которая не разобралась со своими — же обёртками над своим — же парсером.
МР>XXXFormater Это же просто обертка над разными сериализаторами.
МР>Эти 2 сериализатора сделаны разными людьми, используют разную разметку атрибутами и работают местами по-разному. Есть даже довольно большая статья в MSDN по миграции с одного на другой Migrate from Newtonsoft.Json to System.Text.Json — там явно не всё, но даже этого — выше крыши.
Да, я всё это читал, но через интерфейсы этих обёрток всё равно не пробиться к парсеру напрямую, кроме как самому всё разгребать — т.е. переписать ядро библиотеки — т.е. нафейфуа она тогда мне вообще? Ни перегрузок, чтобы переопределять поведение, ни свойств. Просто бери — копируй код и меняй потроха. Не таким я себе представлял Open Source.
МР>Ну а то, что ребята не стали завязываться на какой-то один сериализатор, а сделали возможность использовать тот, который вам удобнее — это же наоборот отлично!
Только сторонний работает по своей-же документации, а свой — нет. Просто молодцы, чё!
МР>Вы просто выберите какой-то один, который вам подходит больше и остановитесь на нем.
Поведение разное, несмотря на то, сама спецификация JsonRpc — на полторы страницы в хроме. Какая разница какой парсер? Есть метод, есть параметры, есть результат — работай (атрибуты — это, действительно, fine tunning, опустим их)
D>>Ничего, кроме негатива, не испытал исследуя эту либу (официальную от Майков!!!)
МР>Ну если весь негатив сводится к различию в поведении JSON-сериализаторов, которые являются внешними по отношению к этой библиотеке, то для меня библиотека выглядит вполне приличной.
Плюс кастомизация, переопределение поведения (см. выше).
Да и поведение не надо быбло бы менять, если бы с парсерами проблем не было бы таких диких.
МР>Я, откровенно говоря, не помню, чтобы где-то в документации или статьях на неё особо ссылались. Даже та же gRPC встречается куда чаще.
Нужен протокол JsonРpc, не Grpc. И эта либа единственная от microsoft (мы не хотим стороннего из — за бюрократии, но это другая проблема).
Re[5]: .NET ненависти псто
Здравствуйте, Михаил Романов, Вы писали:
D>>Если клиент использует SystemTextJsonFormatter, то параметры не сериализуются. А с JsonMessageFormatter — нет проблем.
МР>А какое поведение вы ожидаете?
Хотелось бы, чтобы заявленное поведение всё-таки присутсввовало независимо от используемого паерсера. В данном случае — это ядро библиотеки, которая не разобралась со своими — же обёртками над своим — же парсером.
МР>XXXFormater Это же просто обертка над разными сериализаторами.
МР>Эти 2 сериализатора сделаны разными людьми, используют разную разметку атрибутами и работают местами по-разному. Есть даже довольно большая статья в MSDN по миграции с одного на другой Migrate from Newtonsoft.Json to System.Text.Json — там явно не всё, но даже этого — выше крыши.
Да, я всё это читал, но через интерфейсы этих обёрток всё равно не пробиться к парсеру напрямую, кроме как самому всё разгребать — т.е. переписать ядро библиотеки — т.е. нафейфуа она тогда мне вообще? Ни перегрузок, чтобы переопределять поведение, ни свойств. Просто бери — копируй код и меняй потроха. Не таким я себе представлял Open Source.
МР>Ну а то, что ребята не стали завязываться на какой-то один сериализатор, а сделали возможность использовать тот, который вам удобнее — это же наоборот отлично!
Только сторонний работает по своей-же документации, а свой — нет. Просто молодцы, чё!
МР>Вы просто выберите какой-то один, который вам подходит больше и остановитесь на нем.
Поведение разное, несмотря на то, сама спецификация JsonRpc — на полторы страницы в хроме. Какая разница какой парсер? Есть метод, есть параметры, есть результат — работай (атрибуты — это, действительно, fine tunning, опустим их)
Хотелось взять майковский парсер, пока не задолбался выяснять почему с клиента не приходят пораметры, хотя по документации должны. Пришлось попробовать другой, а у него интерфейс другой, и работает он по-другому. А spec протокола — простой как три копейки — это вообще от парсера не должно зависеть 😫
D>>Ничего, кроме негатива, не испытал исследуя эту либу (официальную от Майков!!!)
МР>Ну если весь негатив сводится к различию в поведении JSON-сериализаторов, которые являются внешними по отношению к этой библиотеке, то для меня библиотека выглядит вполне приличной.
Плюс кастомизация, переопределение поведения (см. выше).
Да и поведение не надо быбло бы менять, если бы с парсерами проблем не было бы таких диких.
МР>Я, откровенно говоря, не помню, чтобы где-то в документации или статьях на неё особо ссылались. Даже та же gRPC встречается куда чаще.
Нужен протокол JsonРpc, не Grpc. И эта либа единственная от microsoft (мы не хотим стороннего из — за бюрократии, но это другая проблема).
D>>Если клиент использует SystemTextJsonFormatter, то параметры не сериализуются. А с JsonMessageFormatter — нет проблем.
МР>А какое поведение вы ожидаете?
Хотелось бы, чтобы заявленное поведение всё-таки присутсввовало независимо от используемого паерсера. В данном случае — это ядро библиотеки, которая не разобралась со своими — же обёртками над своим — же парсером.
МР>XXXFormater Это же просто обертка над разными сериализаторами.
МР>Эти 2 сериализатора сделаны разными людьми, используют разную разметку атрибутами и работают местами по-разному. Есть даже довольно большая статья в MSDN по миграции с одного на другой Migrate from Newtonsoft.Json to System.Text.Json — там явно не всё, но даже этого — выше крыши.
Да, я всё это читал, но через интерфейсы этих обёрток всё равно не пробиться к парсеру напрямую, кроме как самому всё разгребать — т.е. переписать ядро библиотеки — т.е. нафейфуа она тогда мне вообще? Ни перегрузок, чтобы переопределять поведение, ни свойств. Просто бери — копируй код и меняй потроха. Не таким я себе представлял Open Source.
МР>Ну а то, что ребята не стали завязываться на какой-то один сериализатор, а сделали возможность использовать тот, который вам удобнее — это же наоборот отлично!
Только сторонний работает по своей-же документации, а свой — нет. Просто молодцы, чё!
МР>Вы просто выберите какой-то один, который вам подходит больше и остановитесь на нем.
Поведение разное, несмотря на то, сама спецификация JsonRpc — на полторы страницы в хроме. Какая разница какой парсер? Есть метод, есть параметры, есть результат — работай (атрибуты — это, действительно, fine tunning, опустим их)
Хотелось взять майковский парсер, пока не задолбался выяснять почему с клиента не приходят пораметры, хотя по документации должны. Пришлось попробовать другой, а у него интерфейс другой, и работает он по-другому. А spec протокола — простой как три копейки — это вообще от парсера не должно зависеть 😫
D>>Ничего, кроме негатива, не испытал исследуя эту либу (официальную от Майков!!!)
МР>Ну если весь негатив сводится к различию в поведении JSON-сериализаторов, которые являются внешними по отношению к этой библиотеке, то для меня библиотека выглядит вполне приличной.
Плюс кастомизация, переопределение поведения (см. выше).
Да и поведение не надо быбло бы менять, если бы с парсерами проблем не было бы таких диких.
МР>Я, откровенно говоря, не помню, чтобы где-то в документации или статьях на неё особо ссылались. Даже та же gRPC встречается куда чаще.
Нужен протокол JsonРpc, не Grpc. И эта либа единственная от microsoft (мы не хотим стороннего из — за бюрократии, но это другая проблема).