Size: a a a

2020 July 22

В

Владислав in F# Chat
наверное ты про это?
источник

ДБ

Дмитрий Башинский... in F# Chat
Это я смотрел, но к этой статье тоже есть вопросы.
Модели это Record?
Как сделать асинхронную кверю?
источник

В

Владислав in F# Chat
стоит подождать адептов чтобы они все на свои места
источник

В

Владислав in F# Chat
если интересней этого ничего нет, то у меня вопросы к тому, как на f# писать бэк
источник

VK

Vladislav Khapin in F# Chat
даппер если нужен
источник

ДБ

Дмитрий Башинский... in F# Chat
Есть репозиторий с примером бекенда?
Хочу увидеть типы, работу с ними, бд
источник

PD

Prunkles Dreemurr in F# Chat
Владислав
мешать с и ф вместе проблемно?
Разве что для райдера придётся каждый раз билдить C# проект, чтобы обновить IntelliSense для зависимого F# проекта
источник

В

Владислав in F# Chat
Перед коммитом происходит билд и факапа не будет
источник
2020 July 23

AV

Alex Varenik in F# Chat
Vladimir Shchur
для инсертов есть dapper.contrib
https://github.com/CollaboratingPlatypus/PetaPoco/wiki/Quick-Start мне больше понравился, тут достаточный минимализм изначально более правильный чем в даппере.
источник

A

AlexxSt in F# Chat
Дмитрий Башинский
кто использовал F# record + EF?
Использование фарша с еф это источник постоянных проблем. Первое, что будет недоступно, это миграции (вроде бы, есть мигратор для фарша, но он сдох не родившись, устанавливается при помощи магии, имеет кучу багов и многое не поддерживает).
Второе - для корректной работы фарша и еф в фарше приходится объявлять странные структуры с виртуальными полями и аттрибутами, иначе рефлексия в еф не находит нужные свойства и не инициализирует их.

Я обычно делаю проект на с#, туда выношу все энтити для работы с бд и  сам класс контекста(иногда несколько). А логика приложения на фарше в другой сборке.
источник

Dv

Dr. Friedrich von Ne... in F# Chat
Igor
Хм, вопрос был скорее про "архитектурный подход".
Типа на каких слоях остается task, а где async?
Сразу конвертите или стараетесь использовать task по максимуму?
Я бы везде использовал tasks и не мучил мозг.
источник

Dv

Dr. Friedrich von Ne... in F# Chat
Igor
Еще недавно столкнулся c C# Threading.Channels.Channel, тк не нашел в F# альтернативы.
Пришлось поприсаживаться с ValueTask 😐
TaskBuilder умеет в интероп с ValueTask, если что.
источник

VS

Vladimir Shchur in F# Chat
AlexxSt
Использование фарша с еф это источник постоянных проблем. Первое, что будет недоступно, это миграции (вроде бы, есть мигратор для фарша, но он сдох не родившись, устанавливается при помощи магии, имеет кучу багов и многое не поддерживает).
Второе - для корректной работы фарша и еф в фарше приходится объявлять странные структуры с виртуальными полями и аттрибутами, иначе рефлексия в еф не находит нужные свойства и не инициализирует их.

Я обычно делаю проект на с#, туда выношу все энтити для работы с бд и  сам класс контекста(иногда несколько). А логика приложения на фарше в другой сборке.
дополню, использование еф это боль, кучу времени будет потрачено на борьбу с ним, на всех больших проектах где я был - юзалось все кроме него, на мелких, где он был - я помню кучу головняка связанного с ним (это все про сишарп)
источник

nb

n bns in F# Chat
Vladimir Shchur
дополню, использование еф это боль, кучу времени будет потрачено на борьбу с ним, на всех больших проектах где я был - юзалось все кроме него, на мелких, где он был - я помню кучу головняка связанного с ним (это все про сишарп)
А какие например могут быть проблемы? Использовал только ef core под postgresql на c#, во всем устраивало.
источник

A

AlexxSt in F# Chat
Vladimir Shchur
дополню, использование еф это боль, кучу времени будет потрачено на борьбу с ним, на всех больших проектах где я был - юзалось все кроме него, на мелких, где он был - я помню кучу головняка связанного с ним (это все про сишарп)
А у меня совершенно другой опыт. В крупных и мелких проектах он делал и делает ровно то, что я от него жду и головной боли пока не имел. Ни с запросами, ни с миграциями, ни со сменой субд.

Поделитесь проблемами с ним?
источник

VS

Vladimir Shchur in F# Chat
Vladimir Shchur
Приберегал видос для следующего такого запроса) https://www.youtube.com/watch?v=TQHgaDfrDmE&t=18s
YouTube
Почему в 2020 году не нужна своя реализация паттерна Repository
Трудно представить себе приложение на платформе .NET, которое не использует базу данных. Именно поэтому паттерны для организации доступа к данным так актуальны. Репозиторий, описанный Фаулером в своей книге PoEAA около 20 лет назад, даже сейчас можно увидеть во многих новых проектах, в том числе микросервисах. Однако теперь он реализуется с использованием ORM и многие лидеры .NET сообщества, такие как Jimmy Bogard (автор MediatR и AutoMapper) говорят, что такая реализация не имеет смысла и отказываются от нее, используя напрямую ORM. Кто же прав, сторонники классического или современного подходов?
Доклад подробно раскроет эту тему и покажет, что репозиторий не дает преимуществ ни при миграции проекта между базами, ни между ORM. Что дополнительные решаемые репозиторием задачи, типа инкапсуляции и комбинации запросов не менее эффективно решаются и без него. Также в докладе будет информация о положительном опыте отказа от репозиториев и безболезненного рефакторинга ряда проектов. Такой опыт будет очень полезен всем…
вот этот сначала посмотрите видос
источник

A

AlexxSt in F# Chat
Vladimir Shchur
вот этот сначала посмотрите видос
В нем рассказывается о ваших проблемах? Очень интересно.

А что касается отказа от репозиториев, то это идея не нова. Еф сам по себе является реализацией концепции репозитория в какомто смысле.
источник

MS

Mark Shevchenko in F# Chat
AlexxSt
А у меня совершенно другой опыт. В крупных и мелких проектах он делал и делает ровно то, что я от него жду и головной боли пока не имел. Ни с запросами, ни с миграциями, ни со сменой субд.

Поделитесь проблемами с ним?
Обычно проблемы бывают, когда сценарий кардинально отличается от того, что предлагает EF. Там в основе Unit of Work, поэтому сценарии c короткими запросами на изменении хорошо ложатся на EF. Плохо ложится "произвольный" или производительный доступ к базе.
источник

VS

Vladimir Shchur in F# Chat
кроме этого - на порядок больше времени на старте, особенно при code first, кучу надо приседаний сделать чтобы нужной схемы добиться, потом - пришлют тебе медленный запрос, гораздо тяжелее разобраться откуда в коде он пришел и так же тяжело его оптимизировать, далее часто вместо того чтобы оптимальный запрос сделать, ты делаешь более "удобный" с точки зрения EF, плюс кучи проблем из-за апгрейдов самого ef, ломающих изменений, ну и в о общем, вместо того чтобы разбираться с базой ты должен разбираться в тонкостях фреймворка (забивать голову ненужными делами), плюс времена когда у тебя только sql уже давно прошли, все чаще надо ориентироваться на nosql базу, так что завязываться на orm становиться все более плохой идеей
источник

VS

Vladimir Shchur in F# Chat
AlexxSt
В нем рассказывается о ваших проблемах? Очень интересно.

А что касается отказа от репозиториев, то это идея не нова. Еф сам по себе является реализацией концепции репозитория в какомто смысле.
там грабли, на которые я наступал в том числе)
источник