Comments 24
NFX разве можно без их фреймворка юзать?
Scratch: В этом-то все и дело! Весь NFX — в одном dll. Он в этом каталоге.
Представляете, весь фрамеворк — в одном dll. Никаких проблем с версионностью, с потерянными ссылками и т.п.
Многие спросят, а зачем мне этот паравоз, мне только сериализатор нужен. А тут еще полноценная замена WCF на стероидах, доступ к базам, хостинг, кластеры… Можно ли оставить только сериализатор?
Ответ: нет. Вся суть этого подхода, Unistack, именно в этом. Попробуйте, может понравится. Все это хозяйство грузится за долю секунды и сразу же готово к работе. 1.5 МБ, — на мой взгляд, это небольшая плата.
Представляете, весь фрамеворк — в одном dll. Никаких проблем с версионностью, с потерянными ссылками и т.п.
Многие спросят, а зачем мне этот паравоз, мне только сериализатор нужен. А тут еще полноценная замена WCF на стероидах, доступ к базам, хостинг, кластеры… Можно ли оставить только сериализатор?
Ответ: нет. Вся суть этого подхода, Unistack, именно в этом. Попробуйте, может понравится. Все это хозяйство грузится за долю секунды и сразу же готово к работе. 1.5 МБ, — на мой взгляд, это небольшая плата.
Многие спросят, а зачем мне этот паравоз, мне только сериализатор нужен. А тут еще полноценная замена WCF на стероидах, доступ к базам, хостинг, кластеры… Можно ли оставить только сериализатор?
Вопрос не в том, «можно ли оставить», вопрос в том, что делать, если нужен только сериализатор.
Хм, помнится когда я описывал наш Walkable (LINQ для JS), все как раз настоятельно советовали юзать сторонние библиотеки невзирая на их избыточность )
lair Честно говоря, не уверен, что сериализатор можно «вытащить» из NFX. Надо у его автора спросить.
Однозначно, это вытаскивание идет вразрез с идеей Unistack. Для работы с ним вам не надо подгружать никаких доп.библиотек. Это не идея швейцарского ножа с сотней мелочей. Это, скорее, "OK Google".
Однозначно, это вытаскивание идет вразрез с идеей Unistack. Для работы с ним вам не надо подгружать никаких доп.библиотек. Это не идея швейцарского ножа с сотней мелочей. Это, скорее, "OK Google".
Это не идея швейцарского ножа с сотней мелочей. Это, скорее, «OK Google».
Плохая метафора, «ок, гугл» может слишком много и поэтому все по отдельности делает плохо. Не согласны — попробуйте с его помощью проложить пеший трек по Исландии.
Я не хочу обсуждать достоинства/недостатки монолитных систем, я просто хочу понимать, что нужно, чтобы воспользоваться всеми сериализаторами, задействованными в сравнении.
Согласен, универсальный тул по каждому входящему тулу хуже, чем специализированный тул. Поэтому мне аналогия со швейцарским ножом и не нравится.
Опять же согласен, что «ОК Google» тоже не совсем удачное сравнение.
Хммм… Попробую такое сравнение: топор, которым срубили Кижи. Или статуя, сделанная из глыбы, от которой отсекли все лишнее.
Или — LINQ.
Выбран самый нужный функционал для профи. Отброшено все, что упрощает работу для новичков. редко используемы сигнатуры, интерфейсы. Полученный концентрат можно использовать вдоль и поперек. Остался ограниченный набор. Сильно связанный набор! Выдернешь одно и порушишь все. Как болтик из ракеты. Все имеет свой смысл.
Этот набор сделан на общих принципах. Принципов, как и тулов, мало, но достаточно. Если освоишь, то оседлаешь ракету, похожую на топор с формами Венеры Милосской… эко меня понесло.
Или так: горная страна вся связана мостами. Но мосты переброшены только между основными вершинами. Ты можешь их использовать, только если обладаешь достаточными навыками, чтобы забраться хотя бы на одну вершину.
Опять же согласен, что «ОК Google» тоже не совсем удачное сравнение.
Хммм… Попробую такое сравнение: топор, которым срубили Кижи. Или статуя, сделанная из глыбы, от которой отсекли все лишнее.
Или — LINQ.
Выбран самый нужный функционал для профи. Отброшено все, что упрощает работу для новичков. редко используемы сигнатуры, интерфейсы. Полученный концентрат можно использовать вдоль и поперек. Остался ограниченный набор. Сильно связанный набор! Выдернешь одно и порушишь все. Как болтик из ракеты. Все имеет свой смысл.
Этот набор сделан на общих принципах. Принципов, как и тулов, мало, но достаточно. Если освоишь, то оседлаешь ракету, похожую на топор с формами Венеры Милосской… эко меня понесло.
Или так: горная страна вся связана мостами. Но мосты переброшены только между основными вершинами. Ты можешь их использовать, только если обладаешь достаточными навыками, чтобы забраться хотя бы на одну вершину.
Выбран самый нужный функционал для профи.
А кто выбирал? Откуда мне знать, что его выбор подходит для моих задач?
Сильно связанный набор! Выдернешь одно и порушишь все.
Вы, вероятно, хотели сделать решению комплимент, но получилось строго наоборот.
Ты можешь их использовать, только если обладаешь достаточными навыками, чтобы забраться хотя бы на одну вершину.
Спасибо, но мне не надо забираться на вершину, мне надо добраться из точки А в точку Б. Поезд меня вполне устроит.
В этом проблема метафор — они больше выдают чувства автора, нежели описывают суть явления.
Выбран самый нужный функционал для профи.
А кто выбирал? Откуда мне знать, что его выбор подходит для моих задач?
Может и не подойдет. С сожалению, сейчас по NFX мало обзорных статей, мало доступных use cases. Use cases есть, но этот вопрос — к авторам NFX.
Сильно связанный набор! Выдернешь одно и порушишь все.
Вы, вероятно, хотели сделать решению комплимент, но получилось строго наоборот.
Намек на loose coupling? LC — хорошо,
LC предполагает деление системы (модели) на подсистемы, которые уже и будут слабо связаны. NFX сильно связана, в том же смысле, как человек собран из разных частей. Посмотрим на человека, как систему костей и органов, будет одна модель. Посмотрим на человека, как на систему клеток, будет другая модель. NFX здесь больше на клетку похожа. Все в ней взаимно связано. Но при этом клетки объединяются. При этом клетки специализируются.
Намек на loose coupling?
Нет, намек на излишнюю хрупкость.
NFX здесь больше на клетку похожа. Все в ней взаимно связано. Но при этом клетки объединяются.
И с чем объединяется NFX?
Про хрупкость… не понял, туплю.
В NFX есть библиотека Glue, которая Slim сериализатор использует. Что-то типа WCF. Чтобы рассыпать NFX приложения по серверам и связывать их. Представьте, что вам не надо заботиться о коммуникационном пакете, он есть всегда и везде.
В NFX есть библиотека Glue, которая Slim сериализатор использует. Что-то типа WCF. Чтобы рассыпать NFX приложения по серверам и связывать их. Представьте, что вам не надо заботиться о коммуникационном пакете, он есть всегда и везде.
Представьте, что вам не надо заботиться о коммуникационном пакете, он есть всегда и везде.
Я могу его использовать, чтобы связаться с мобильным приложением, написанным на Swift?
Да, можете. Хотя придется данными обмениваться в JSON. Есть NFX JSON сериализатор, в тестах он тоже есть.
Но, естественно, придется на Swift писать кое-что от руки. Если связывать NFX приложение с NFX приложением, то это очень просто и быстро. Slim сериализатор использует свой бинарный формат. В тестах он есть.
Но, естественно, придется на Swift писать кое-что от руки. Если связывать NFX приложение с NFX приложением, то это очень просто и быстро. Slim сериализатор использует свой бинарный формат. В тестах он есть.
В тесте отсутствуют zero-copy parsing библиотеки — например FlatBuffers для C# вполне можно юзать.
Десериализация за 0 сек — это серьёзно ))
Десериализация за 0 сек — это серьёзно ))
notacodemonkey: Да, это серьезно. В наших планах протестировать эти библиотеки.
Но надо понимать, что у них очень ограниченное применение. По сути вы явно выделяете память под объекты и сбрасываете копию памяти в эту выделенную область. Т.е. получается такая unmanaged область, где ваш объект. Вы byte[] выгружаете в эту область и называете это zero-copy.
Похоже, что при этом происходит подмена понятий.
Мы называем сериализацией-десериализацией процесс, в котором на одном конце находятся объекты. А тут — не объекты, а byte[], как и в канале, как и на другом конце. Естественно, время на это затрачивается — почти ничего. То, что приходится уже явно конвертировать этот byte[] в объект, не считается. Это уже не проблема сериализатора, это ваша проблема.
Нам говорят. Вот вам груда кирпичей. Это — дом, за который вы супер дешево заплатили.
Но надо понимать, что у них очень ограниченное применение. По сути вы явно выделяете память под объекты и сбрасываете копию памяти в эту выделенную область. Т.е. получается такая unmanaged область, где ваш объект. Вы byte[] выгружаете в эту область и называете это zero-copy.
Похоже, что при этом происходит подмена понятий.
Мы называем сериализацией-десериализацией процесс, в котором на одном конце находятся объекты. А тут — не объекты, а byte[], как и в канале, как и на другом конце. Естественно, время на это затрачивается — почти ничего. То, что приходится уже явно конвертировать этот byte[] в объект, не считается. Это уже не проблема сериализатора, это ваша проблема.
Нам говорят. Вот вам груда кирпичей. Это — дом, за который вы супер дешево заплатили.
Flat buffers, CAPTN proto etc… these are not serializers, these are memory managers. You can not call them serializers as you can not use the «standard object» paradigm. In other words, you can not copy an instance of FileStream by just copying memory bytes. sorry for english i have little time to answer now
Для сценариев где данные изменять не нужно, и обьект доставать из этого буфера не нужно, потому что эти либы генерируют аксесоры прямо в этот буфер.
da imenno,
eto kak kogda-to xranili v Delphi (naprimer) Dataset v binarnom file na diske. Rows[] — eto byl prosto (byte*)
kotoriy kastalsya cherez FiedlByName(«ColumnName»).
Eto ne serializaija. Eto format xraneniya dannix. On ne transparenten dlya raboti s obektami yazika kotorie na to i objects
chtobi s nimi rabotat (call methods, properties etc...)
eto kak kogda-to xranili v Delphi (naprimer) Dataset v binarnom file na diske. Rows[] — eto byl prosto (byte*)
kotoriy kastalsya cherez FiedlByName(«ColumnName»).
Eto ne serializaija. Eto format xraneniya dannix. On ne transparenten dlya raboti s obektami yazika kotorie na to i objects
chtobi s nimi rabotat (call methods, properties etc...)
Ne zabudte — dostup cherez rekasti pointerov i transformaziju v buffer (byte*) — eto i est «psevdoserializaija» razmazannaya teper po business kody.
Kak skazal Leo_Gan, vam prodali ne dom a grudu kirpichei :)
Naprimer:
myData[«Age»] = 12345;
a esli v buffere xranitsya v BigEndian, a processor rabotaet v little endian? Eto znachit uje zamedlenie.
Tak chto nikakix chudes net i byt ne mojet. Skorost «zero-copy» resheniy eto ne skorost «write to stream» — nado meryat' vse i UCHITIVAT
«nepolnozennost buferov» — nevozmojnost rabotat s etimi dannimi cherez standartnie sredtsva yazika — a znachit eto DTO — a DTO eto govnokod :) (elsi ego mojno izbezhat')
Kak skazal Leo_Gan, vam prodali ne dom a grudu kirpichei :)
Naprimer:
myData[«Age»] = 12345;
a esli v buffere xranitsya v BigEndian, a processor rabotaet v little endian? Eto znachit uje zamedlenie.
Tak chto nikakix chudes net i byt ne mojet. Skorost «zero-copy» resheniy eto ne skorost «write to stream» — nado meryat' vse i UCHITIVAT
«nepolnozennost buferov» — nevozmojnost rabotat s etimi dannimi cherez standartnie sredtsva yazika — a znachit eto DTO — a DTO eto govnokod :) (elsi ego mojno izbezhat')
Sign up to leave a comment.
Tестирование сериализаторов под .NET