Я так и сделал

У меня на работе задача отдаленно напоминает, тоже через du делал

Буду разбираться по ходу, пока что есть время подождать стабильной поддержки Net Standart 2.0, пока просто пишу логику и познаю новый для себя язык. Непонятно на счёт работы механизмов асинхронности (на первый взгляд, нет пока времени разбираться), выглядит не как на VS++ или C#

а зачем его ждать? PCL много лет как работает

У меня на работе задача отдаленно напоминает, тоже через du делал

Там проще через active patterns

Там проще через active patterns

Что именно? АП вместо функций?

Положу здесь, чтобы потом не забыть #прочитать. https://twitter.com/graydon_pub/status/973083923466002433

Прикольно! я вот подбираюсь к тому чтобы на F* session type'ы покодить и попробовать в f# покомпилить

Потому что даже typed akka, как только дело доходит до behavior'ов разваливается и лезут динамические диспатчи сообщений

Session types тут как раз должны помочь

https://youtu.be/4V5aPFaBAxU

Вот ещё на эту тему есть наработки

Кажется, один RFC к F#4.5 реализовали. https://github.com/Microsoft/visualfsharp/pull/4427

Что именно? АП вместо функций?

Угу. Хотя можно и приватный тип с функцией создания

Кажется, один RFC к F#4.5 реализовали. https://github.com/Microsoft/visualfsharp/pull/4427

А когда релиз?

Одному Сайму известно!

Я думаю, он тоже не особо в курсе

Смотрю там тоже с ресурсами люди мучаются)

Они везде мучаются

Хотя там скорее всего как с тайп провайдерами было

а зачем его ждать? PCL много лет как работает

Хочется использовать такие вещи как Entity Framework, версии которого требуют Net Standart 2.0, а старые наборы NuGet удалёны

Хочется использовать такие вещи как Entity Framework, версии которого требуют Net Standart 2.0, а старые наборы NuGet удалёны

EF на андроидном клиенте? EF это серверная фича. она не должна на клиентах жить

EF на андроидном клиенте? EF это серверная фича. она не должна на клиентах жить

ну не руками же на клиенте с бд работать

откуда на клиенте вообще бд?

откуда на клиенте вообще бд?

ну здрасте, данные хранить кэш, настройки, оффлайн инфу

EF на андроидном клиенте? EF это серверная фича. она не должна на клиентах жить

Вполне себе нормально живёт не сам Framework, а его ядро, конкретно SQLite компонента. БД как раз таки нужна, не сильно толстая, но в том числе для хранения данных пользователя, помимо статики.

ну здрасте, данные хранить кэш, настройки, оффлайн инфу

для этого ef не нужен. эти элементарные вещи можно руками обработать если хочется в бд.

для этого ef не нужен. эти элементарные вещи можно руками обработать если хочется в бд.

потом начнутся миграции руками, создание репозиториев руками, маппинг сущностей руками

для этого ef не нужен. эти элементарные вещи можно руками обработать если хочется в бд.

Никто не спорит, что нельзя, но для чего тогда вообще Frameworkи, давайте всё писать сами.

Никто не спорит, что нельзя, но для чего тогда вообще Frameworkи, давайте всё писать сами.

в основном для типобезопасности

больше от них току нет

это про бд фреймворки.

потом начнутся миграции руками, создание репозиториев руками, маппинг сущностей руками

какие миграции. мы про андроидного клиента говорим.

какие миграции. мы про андроидного клиента говорим.

на нём не может быть миграций? приложение не будет никогда меняться с первого релиза?

на нём не может быть миграций? приложение не будет никогда меняться с первого релиза?

в теории может а на практике тот же sqlite миграций не поддерживает. и?

в теории может а на практике тот же sqlite миграций не поддерживает. и?

в ef core поддерживаются миграции sqlite, но сам sqlite не все методы поддерживает - в этом случае придётся в миграции написать вручную sql код но это всё равно лучше, чем полное их отсутствие

в ef core поддерживаются миграции sqlite, но сам sqlite не все методы поддерживает - в этом случае придётся в миграции написать вручную sql код но это всё равно лучше, чем полное их отсутствие

дело хозяйское. можно сидеть ждать нетстандарт2, утяжелить клиента неизвестно на сколько и потом все равно потом писать sql руками. а можно пользоваться тем что еcть уже сейчас. для f# нужно только тайппровайдеры проверить. если работают то ef становится не нужным в любом варианте

тем более что миграции в андроиде практически из коробки есть http://startandroid.ru/ru/uroki/vse-uroki-spiskom/74-urok-34-hranenie-dannyh-sqlite.html

в теории может а на практике тот же sqlite миграций не поддерживает. и?

В году так 2011 чисто в образовательных целях писал свои запаковщики ресурсов в бинарники, и распаковщики с работой по селектам, всё работало (за искл., что вся база падала в ОЗУ большими частями для перебора, связано это было с хранением не только простых полей типов, но и строк, небольших изображений), чекать версию ресурсов и потом мигрировать было неприятно. Писать китайский код особенно.

тем более что миграции в андроиде практически из коробки есть http://startandroid.ru/ru/uroki/vse-uroki-spiskom/74-urok-34-hranenie-dannyh-sqlite.html

Сейчас таргет на Android, потом iOS, возможно что-то ещё, не в планах пока

https://twitter.com/jindraivanek/status/973291380704411648

Привет.

Здравия

Как же вам нравится говно-то всякое в свои проекты тащить.

фонд платиновых цитат :)

Как же вам нравится говно-то всякое в свои проекты тащить.

Поподробнее, пожалуйста

EF - говно, куда уж тут подробней? Изучать кривую либу, только для того, чтобы хранить настройки пользователя и тащить для этого реляционную базу данных - это ООП головного мозга.

Сохраните в JSON, читайте на старте, сбрасывайте на диск при изменениях (атомарно).

Если слишком просто - возьмите protobuf3 какой-нибудь. Там нормальный язык описания структуры + сохранение из коробки + они подумали про версионирование.

Хочется дать леща.

А для кэшей и поиска в приложение нужно Elastic Search Embedded втащить.

Вообще желание писать на F# или .NET клиентов - желание странное при наличии ReactNative. Кто поддерживать-то все это будет?

EF - говно, куда уж тут подробней? Изучать кривую либу, только для того, чтобы хранить настройки пользователя и тащить для этого реляционную базу данных - это ООП головного мозга.

ну давай-те даппер обколемся и будем писать connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

Есть же тайп-провайдеры

Not your grandmother’s ORM

Вообще желание писать на F# или .NET клиентов - желание странное при наличии ReactNative. Кто поддерживать-то все это будет?

Ну извините, группа то называется F#. Если конкретно, то из EF используется только <b>один</b> класс при переопределении, один класс в качестве параметра переопределяемого метода, и одно расширение. Всё остальное селектами. И на счет хранения настроек, мне будет мало JSON|XML, в силу очень большого объема данных.

Очень большой объём данных на клиенте? Rly?

Вообще желание писать на F# или .NET клиентов - желание странное при наличии ReactNative. Кто поддерживать-то все это будет?

Блин, как будто реакт нейтив это до невозможности идеальное решение, прямо вот без костылей и багов =\ что вы человека пытаетесь переубедить в самом деле, у него может предметная область специфичная или требования и его проблемы идеально решает еф, а вы ему про свой реакт нейтив не разобравшись в задаче

Очень большой объём данных на клиенте? Rly?

У меня нет денег на сервер, защиту от DDOS и денег на шифрование

А можно поинтересоваться, позиция в компании какая? Serious Enterprise Architect?

А можно поинтересоваться, позиция в компании какая? Serious Enterprise Architect?

Я не работаю программистом.

Это многое объясняет.

У меня нет денег на сервер, защиту от DDOS и денег на шифрование

а что будет с большим объемом данных на клиенте если пользователь скажет "очистить данные приложения"?

Ну извините, группа то называется F#. Если конкретно, то из EF используется только <b>один</b> класс при переопределении, один класс в качестве параметра переопределяемого метода, и одно расширение. Всё остальное селектами. И на счет хранения настроек, мне будет мало JSON|XML, в силу очень большого объема данных.

Я бы посоветовал Dapper взять. Я его и на (маленьком) бекенде юзаю - из f# норм работает. Плюс, там ссылку выше кидали, что сделали удобную обертку для f# А еще есть LiteDb - это встраиваемая nosql база, для .net

Но вообще не могу представить ни одного кейса, где EF был бы сколько нибудь лучше других инструментов F#

Dagger на +20% к скорости атаки!

Скажите, чем тайп-провайдеры не подходят?

Но вообще не могу представить ни одного кейса, где EF был бы сколько нибудь лучше других инструментов F#

Кросс-платформенно, пожалуйста

В смысле оно под мобилки не работает? Я просто не в курсе.

Оно же по идее на этапе конпеляции работает, а там моно, не?

а что будет с большим объемом данных на клиенте если пользователь скажет "очистить данные приложения"?

То же, что и в других приложениях без синхронизации с облаком, пользователь теряет свои данные.

А как пользователь без внешней БД сможет сделать ОЧЕНЬМНОГОДАННЫХ у себя?

Экспрешоны не компилятся вроде на иосе из-за его политики

Даже без описания приложения, уже очень странные звоночки.

Просто в БД надо хранить не только его "настройки", также много статик даты, которую просто удобно извлечь из с помощью EF

А как пользователь без внешней БД сможет сделать ОЧЕНЬМНОГОДАННЫХ у себя?

нафотать

И положить в реляционную базу данных фотки?

Чтобы потом EF их оттуда доставал?

И положить в реляционную базу данных фотки?

Нет, не фото, приложение генерирует дату само.

А для кэшей и поиска в приложение нужно Elastic Search Embedded втащить.

Нужно взять данные из бд @ установи стек весом в десятки гб оперативы

Нужно взять данные из бд @ установи стек весом в десятки гб оперативы

Дя!

Норм совет.

Красненького в телеграм не завезли, сорян.

Норм совет.

Ещё можно микросервисов наделать в клиенте, для улучшения дизайна.

Нужно взять данные из бд @ установи стек весом в десятки гб оперативы

Не понимаю юмора

Ох уж эта пост-ирония!

Ну а что ещё делать, пока на работу едешь.

Оно же по идее на этапе конпеляции работает, а там моно, не?

Должны работать.

Ну вот мне тоже кажется, что все должно работать, я не проверял хотя.

Есть же тайп-провайдеры

которые любят падать на простых запросах внутри себя

лучше уж даппер

которые любят падать на простых запросах внутри себя

Пример?

Пример?

его нет, это более полугода назад было

Ссылка на issue на гитхабе?

его нет, это более полугода назад было

Я расцениваю это, как враньё, и пропаганду.

Я расцениваю это, как враньё, и пропаганду.

ну можешь расценивать, я свой опыт говорю

Господа, полегче с обвинениями. @pavelkhritonenko