Не самая плохая идея.

Да, обычный dependency inversion.

А чо такое send_message1 .. send_message7?

Команды бота

Это для примера?

Меня просто удивили такие, гм, невзрачные названия

Если это пример то ок.

Это тестовый бот :)

Чтобы проверять корректность работы функций

Поясните за инверсию контроля в фп, я так понимаю, так же просто, как в ООП, разруливать зависимости не возможно?

1) "Инверсия контроля" - не праильный термин, за который тебя накажут на любом собеседовании. Правильный - dependency injection (внедрение зависимостей). 2) То, что расказывает лектор в видео по ссылке @gsomix, ни чего общего с реальными практиками DI не имеет от слова вообще. Для ФП DI - параллельная всселенная 3) Dependency injection может неплохо выглядеть в теории. Но на практике она бесполезна и обычно ведет к усложнению кода. Могу популярно объяснить почему так

Есть еще dependency inversion

@ruzzke_mir Я никаких видео не кидал.

>Могу популярно объяснить почему так Давай, очень интересно.

Хотя про di у меня есть пара историй из реальной жизни

@ruzzke_mir Я никаких видео не кидал.

ошибся прошу прощения. Видео от @Igor

@ruzzke_mir А dependency inversion -- это прямо из SOLID.

Ну, и калька на русском -- инверсия зависимостей.

@ruzzke_mir ServiceLocator is the cornerstone of any enterprise application :)

Наверное, инверсия контроля откуда-то оттуда.

В общем,коллеги,DI-действительно дорога в ад

1) "Инверсия контроля" - не праильный термин, за который тебя накажут на любом собеседовании. Правильный - dependency injection (внедрение зависимостей). 2) То, что расказывает лектор в видео по ссылке @gsomix, ни чего общего с реальными практиками DI не имеет от слова вообще. Для ФП DI - параллельная всселенная 3) Dependency injection может неплохо выглядеть в теории. Но на практике она бесполезна и обычно ведет к усложнению кода. Могу популярно объяснить почему так

Ты его хоть смотрел? P.S. Мне кажется ты ошибочно считаешь что обладаешь абсолютными знаниями (спорить с тобой я конечно не буду). (и имя мое даже набрал неправильно)

IoC -из Solid

@angmarr все хотят, чтобы их считали умными :)

А если по делу, то идея с рекордами функций интересная

Ты его хоть смотрел? P.S. Мне кажется ты ошибочно считаешь что обладаешь абсолютными знаниями (спорить с тобой я конечно не буду). (и имя мое даже набрал неправильно)

Не считаю, но про DI знаю достаточно. Видео начал смотреть, но не досмотрел, поскольку пойнт мне ясен.

Симан,кстати , недавно относительно каялся по поводу ServiceLocator

Года три назад вроде

Симан,кстати , недавно относительно каялся по поводу ServiceLocator

Самое лучшее - это вообще забить на подобные понятия и не принимать их в расчёт на практике.

Мне не хватает стикера с кэпом

Привет!

Добре!

Самое лучшее - это вообще забить на подобные понятия и не принимать их в расчёт на практике.

Dependency injection это нормально, все ими везде пользуются (передача ссылки на сервис в конструкторе или в аргументе метода). А вот всякие заумные DI фреймворки, делающие magic, это зло.

Dependency injection это нормально, все ими везде пользуются (передача ссылки на сервис в конструкторе или в аргументе метода). А вот всякие заумные DI фреймворки, делающие magic, это зло.

DI контейнер может гораздо лучше управлять сложностью, вложенной в процесс преобразования абстракций к конкретным типам, и управлять их жизненными циклами. С ним проще делать механизмы перехвата и декораторы. Но если ты считаешь, что DI - это хорошо, ответь для себя (здесь не надо) на такие вопросы:

— Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации? — Как узнать, когда, в каком порядке и с какими аргументами были инициализированы зависимости, использующиеся в конкретной области кода? Как это влияет на debuggability и maintainability кода? — Как повлиять на порядок инициализации зависимостей и аргументы, используемые при их инициализации? — Как сделать так, чтобы определенные зависимости создавались при каждом вызове функции, а другие — использовались повторно? — Какие проблемы решает DI? Стоит ли решение этих проблем добавления геморроя по вышеуказанным вопросам?

— Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации? — Как узнать, когда, в каком порядке и с какими аргументами были инициализированы зависимости, использующиеся в конкретной области кода? Как это влияет на debuggability и maintainability кода? — Как повлиять на порядок инициализации зависимостей и аргументы, используемые при их инициализации? — Как сделать так, чтобы определенные зависимости создавались при каждом вызове функции, а другие — использовались повторно? — Какие проблемы решает DI? Стоит ли решение этих проблем добавления геморроя по вышеуказанным вопросам?

Полностью согласен, и поэтому DI фреймворки это зло, к понятию DI это всё не имеет отношения. DI это просто передача зависимости на один уже созданный сервис другому. Можно передать ссылку на объект, не обязательно создавать интерфейс. Можно создавать объекты самому. Всё остальное от лукавого.

— Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации? — Как узнать, когда, в каком порядке и с какими аргументами были инициализированы зависимости, использующиеся в конкретной области кода? Как это влияет на debuggability и maintainability кода? — Как повлиять на порядок инициализации зависимостей и аргументы, используемые при их инициализации? — Как сделать так, чтобы определенные зависимости создавались при каждом вызове функции, а другие — использовались повторно? — Какие проблемы решает DI? Стоит ли решение этих проблем добавления геморроя по вышеуказанным вопросам?

Аплодирую стоя.

— Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации? Чтобы взяли на работу

— Зачем заводить кучу бесполезных интерфейсов ради DI, если за большинством таких интерфейсов на практике редко бывает более одной реализации? Чтобы взяли на работу

воот!

сидишь обмазанный сервисами, заобстрагировался интерфейсами с одним методом и единственной релизацией и ищешь работу

Короче я так и не понял из вашего обусждения, DI это плохо, или хорошо?

или DI с интерфейсами - плохо, а DI без интерфейсов - хорошо?

DI хорошо не везде

и не всегда

В меру, я бы сказал

ну это мой поинт

Не стоит его в абсолют возводить

Короче я так и не понял из вашего обусждения, DI это плохо, или хорошо?

DI это процесс передачи зависимости и имплементирован он может быть по разному. Например использовать DI фреймворк какой-нибудь, чего по моему мнению делать не надо, т.к. куча геморроя от него. Можно руками всё​ делать, через конструктор или аргумент функции, что хорошо, т.к. всё под контролем.

== DI это просто передача зависимости на один уже созданный сервис другому. Можно передать ссылку на объект, не обязательно создавать интерфейс. так это не DI. Это тривиальное действие в коде, не требующее для себя определения. Что-то вроде вызозова функции с аргументами :) DI - это именно про интерфейсы, декораторы и различные ОПП-паттерны. ИМХО всем надо прочитать хотя бы одну книжку по ООП какого нибудь дядюшки боба. Что-бы не путаться в терминологии и при случае по издеваться над упоровшимися оопшниками :)

Книжки дядюшки боба тоже зло

Я просто тупо беру понятие DI из Фаулера. Он тоже чёткого определения не даёт, но смысл приводит на 50...100 листах. Сосбственно понятие не техническое ни разу, поэтому и нормального определения нет

Я просто тупо беру понятие DI из Фаулера. Он тоже чёткого определения не даёт, но смысл приводит на 50...100 листах. Сосбственно понятие не техническое ни разу, поэтому и нормального определения нет

In software engineering, dependency injection is a technique whereby one object supplies the dependencies of another object. A dependency is an object that can be used (a service). An injection is the passing of a dependency to a dependent object (a client) that would use it. The service is made part of the client's state.[1] Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern.

Всё остальное наворотили теоретики от ООП

Service Locator кстати нарушает этот принцип

Приведите пример из реальной жизни, где без использования dependency injection не обойтись.

Приведите пример из реальной жизни, где без использования dependency injection не обойтись.

Обойтись можно везде, получится по разному.

А то куда ни плюнь, везде hello world enterprise edition.

Ребята, извините, но SOLID и DI это не про ООП.

In software engineering, dependency injection is a technique whereby one object supplies the dependencies of another object. A dependency is an object that can be used (a service). An injection is the passing of a dependency to a dependent object (a client) that would use it. The service is made part of the client's state.[1] Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern.

это устарело :) В другой книге он описывает DI как обстракный набор принципов и шаблонов проектирования программного обеспечения, которые дают возможность разрабатывать слабосвязанный код (естественно я своими словами) В любом случае это определение абсолютно бесполезно. Под поняте "one object supplies the dependencies of another object." можно подветси практически всё что угодно. Реальное DI в кроваваом ынтерпрайзе - это именно то, о чём я выше говорил

Народ, а через MySQL Type Provider же можно создавать таблицы и заполнять их данными?

Если вы хотите обсуждать это в контексте ООП, в том виде, например, какое встречается в C# или Java, то лучше найти более подходящий чат.

Слишком много флуда от этой темы.

это устарело :) В другой книге он описывает DI как обстракный набор принципов и шаблонов проектирования программного обеспечения, которые дают возможность разрабатывать слабосвязанный код (естественно я своими словами) В любом случае это определение абсолютно бесполезно. Под поняте "one object supplies the dependencies of another object." можно подветси практически всё что угодно. Реальное DI в кроваваом ынтерпрайзе - это именно то, о чём я выше говорил

Так теория она вся очень абстрактна и повернута может быть по разному. Но согласен. Уже много флуда ))

Об этом хорошо за пивом болтать ))

У меня цель: Создать 2 таблицы в MySQL. Users, Files. С такой связью: один юзер - много файлов (один-ко-многим)

Хочу сделать это через F#

такое реально?

Приведите пример из реальной жизни, где без использования dependency injection не обойтись.

DI фреймворки скорее просто облегчают интеграцию с другими фреймворками. Например, ты хочешь чтобы какая-нибудь зависимость создавалась по одному разу на каждый http запрос к asp.net mvc. Можешь тогда воспользоваться каким-нибудь autofac с поддержкой asp.net mvc и получить нужное поведение одной строчкой в кофигурации контейнера.

Если вы хотите обсуждать это в контексте ООП, в том виде, например, какое встречается в C# или Java, то лучше найти более подходящий чат.

ну так ты бы привёл пример что-ли SOLID и DI в ФП или написал соими словами как ты себе это представляешь.

@ruzzke_mir Это приведет лишь к дополнительному флуду. Я уже кидал статью polytypic про SOLID, например.

У меня цель: Создать 2 таблицы в MySQL. Users, Files. С такой связью: один юзер - много файлов (один-ко-многим)

А какой именно вопрос тут про F#?

Ну то есть ты хочешь выполнить DDL из F#? Или смоделировать вот эту свою предметную область?

@fvnever TypeProvider

Для MySQL были какие-то тайппровайдеры, но я сам с ними не работал. Надо искать :)

ну на EF через C# я бы создал энтити и выполнил дб апдейт

Кажись, SqlProvider умеет, а SqlCommandProvider не умеет.

вопрос - как на F# это сделать?

У меня цель: Создать 2 таблицы в MySQL. Users, Files. С такой связью: один юзер - много файлов (один-ко-многим)

А зачем создавать таблицы через провайдер? :) Через провайдер удобно получать-добавлять записи

Верно, на F# обычно делают наоборот.

@nevoroman а, я значит не совсем правильно понимаю как работает провайдер

точнее - для чего он нужен.

Я думал sqlProvider это замена EF в F#

У тебя source of truth — это твоя база данных. Ты вручную (или миграционными скриптами) формируешь БД, а потом через провайдеры формируешь типы для доступа к этой БД.

Провайдер нужен для упрощения доступа к данным. EF для формирования базы удобен в том контексте, что ты сначала создаешь модели, а потом по ним создается БД (Model First оно же). А SQL Provider работает как Database First - то есть в бэкграунде создает вот эти самые модели по таблицам в базе. Соответственно, логично сначала спроектировать-создать базу, а потом работать с данными в ней через провайдер.

Ага... Теперь понятно. Но тоесть после создания базы ручками, я смогу вставлять туда данные через провайдер, так ?

Ага

@nevoroman и вот этим мне нужно для этого пользоваться, так ? https://fsprojects.github.io/SQLProvider/core/mysql.html

Да, это оно

Так, базу создал. Нужно попробовать этот тайп провайдер.

@nevoroman вопрос наверное очень детский... Но где найти все эти методы для добавления, удаления и остальных CRUD у тайп провайдера ?

@nevoroman вопрос наверное очень детский... Но где найти все эти методы для добавления, удаления и остальных CRUD у тайп провайдера ?

https://fsprojects.github.io/SQLProvider/core/crud.html

https://fsprojects.github.io/SQLProvider/core/crud.html

Опередил

спасибо

Там документация общая для обращения к любым SQL базам - отличается только dbVendor

Спасибо больше. И ещё вопрос - а из нугета ставить пакет вот этот?

Это же не тот

Вот этот https://www.nuget.org/packages/SQLProvider

Тебе надо SqlProvider, а то SqlClient.