@fsharp_flood - страница 2516

Николай

А вдруг завтра понадобится другая имплементация? А как ты мокать будешь в тестах?

Vasily

Мокнем академика (с)

TOV_MULTIMASSO

Мокать там понадобиться ровно один aggregation root вешь, добавлять в руку 3 сустава для этого не обязательно

Хаскель

Можно) Вот хотел я добавить кастомный репортер, мало того что несколько репортеров не поддерживается, так и интерфейс репортера непонятный, какие методы за что отвечают - хз

Это какая-то штука для тестов?.. У меня задачи типа "загрузиться в мыльную службу, одну из 20", там всё влёт.

Stas

О, нашёл ItemUtil.getInstance().getFlinkCompFunctionProvider().getInstance().getCompFunction().invoke(item) вся эта хуина работает через Guice (DI фреймворк), почти все эти вызовы возвращают интерфейсы, у которых есть единственная имплементация, которая возвращается через провайдер (тоже через DI естесна) и в итоге функция проверяет на null и возвращаает true/ false

расистская функция!

Aleksandr

переименовать в allowedListItem срочно

Николай

Мокать там понадобиться ровно один aggregation root вешь, добавлять в руку 3 сустава для этого не обязательно

У меня сейчас на новой работе сишарповый проект с onion-архитектурой курильщика. Тут не просто на каждом слое все сервисы\репозитории за интерфейсами с единственной имплементацией. Тут ещё и на все сущности и дто навесили интерфейсы, при чём ладно бы маркерные, но нет, интерфейсы с полями, и потом дто с теми же самыми полями. Ну и с xmldoc'ами на каждое поле естественно, без комментария "Наименование" ведь не понять для чего нужно свойство "Name".

Max xbim 🌴

У меня сейчас на новой работе сишарповый проект с onion-архитектурой курильщика. Тут не просто на каждом слое все сервисы\репозитории за интерфейсами с единственной имплементацией. Тут ещё и на все сущности и дто навесили интерфейсы, при чём ладно бы маркерные, но нет, интерфейсы с полями, и потом дто с теми же самыми полями. Ну и с xmldoc'ами на каждое поле естественно, без комментария "Наименование" ведь не понять для чего нужно свойство "Name".

обычное дело ентпрайз галеры

Николай

Аргументация была, что это всё нужно для тестов и для изменения реализации

Николай

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

Николай

На это уже ответов нет.

Aleksandr

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

кричу

Mikhαil

На это уже ответов нет.

Да классика же

Mikhαil

Хотя все дто за интерфейсом эт даже немного неожиданно

Aleksandr

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

у нас отвечают: а что тут тестировать-то?

Vladimir

Это какая-то штука для тестов?.. У меня задачи типа "загрузиться в мыльную службу, одну из 20", там всё влёт.

это куда вывод логов пишется)

Aleksandr

у нас отвечают: а что тут тестировать-то?

ирония в том, что и правда нечего

Aleksandr

некоторые отделыные queryable'ы разве что, но их тоже особо не протестируешь

Shub

У меня сейчас на новой работе сишарповый проект с onion-архитектурой курильщика. Тут не просто на каждом слое все сервисы\репозитории за интерфейсами с единственной имплементацией. Тут ещё и на все сущности и дто навесили интерфейсы, при чём ладно бы маркерные, но нет, интерфейсы с полями, и потом дто с теми же самыми полями. Ну и с xmldoc'ами на каждое поле естественно, без комментария "Наименование" ведь не понять для чего нужно свойство "Name".

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

Shub

xml доки для вроде бы очевидных полей - это тоже не совсем бесполезная штука, мы щас проходим сесурити ревью и нам надо отчитаться по всем существующим полям, и хмл док очень здорово в этом помог

Shub

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

Shub

(интерфейсы на дто никак оправдать нельзя, разумеется)

Mikhαil

(интерфейсы на дто никак оправдать нельзя, разумеется)

Надо уточнить у бугаенко

Shub

я вот недавно спрашивал про энумы. ситуация в своей сути такая: есть жсон, в котором энумы передаются ЗАГЛАВНЫМИ (жава-стайл), нутонсофт разумеется маппит на DU с ЗАГЛАВНЫМИ | КЕЙСАМИ

Shub

в результате у меня в домене есть энумы не по гайдлайнам, потому что я в гробу видел писать конверсии в стиле { name = name }

Danil

name = name ещё и требует контракта с двух сторон

Shub

потому что я решил, что из двух вариантов я пожалуй отступлю от гайдлайнов

Aleksandr

в ньютонософте, емнип, должны быть конвершн хинты в указанием нейминг стратегии

Aleksandr

для таких вещей

Aleksandr

должно лечиться парой атрибутов

Aleksandr

возможно даже из System.ComponentModel.DataAnnotations

Shub

в ньютонософте, емнип, должны быть конвершн хинты в указанием нейминг стратегии

там есть, можно даже написать конверторы. но у меня кое-какие свойства просто перекладываются (статусы там всякие), одна сторона желает ЗАГЛАВНЫЕ, другая сторона желает Фшарп конвенцию. а я типа крутись как можешь

Shub

в жава модели используют СНЕК_КЕЙС, по идее оно должно маппиться на СнекКейс для второй стороны. сомневаюсь, что где-то есть такие конверторы

Aleksandr

ну да, если тут речь про DU, подозреваю что все это значительно сложнее чем с енумами

Shub

ну тут именно что энумы. ограниченный набор строковых значений

Shub

просто в эфшарпе энумы - частный случай DU

Aleksandr

в фшарп есть и обычные System.Enum енумы

Aleksandr

это, те где type A = | X = 1 | Y = 2