просто long = здравствуйте кастомеры, удалённые по айди ордеров. Ну хорошо, если обявление смотрится нормально, то как использование будет выглядеть? как назвать базовый класс для этой штуки? потому что в частности это айди, а бывают случаи когда это какой-то особенный стринг

Просто long имеется в виду вот это: Id<Customer> вместо Id<Customer, long>

а Customer это что

а Customer это что

Тип сущности чей Id мы описываем

а в нём нет Id?

я запутался и мне не нравится ) какой-то целый партизанский отряд с предателем, там где на F# одна строчка кода.

я запутался и мне не нравится ) какой-то целый партизанский отряд с предателем, там где на F# одна строчка кода.

Ну на F# это тоже одной строкой кода описывается. Если нужны другие типы ключа, то можно либо второй дженерик параметр добавить. [<Struct>] type Id<'a> = Id of id: int64

я в упор не понимаю, зачем это

тем более если никакого Customer у меня в поддомене нет

а вот айдишник есть

я в упор не понимаю, зачем это

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

тем более если никакого Customer у меня в поддомене нет

Тогда можно будет сделать маркерный тип для этого.

ну вот это я и имею в виду, когда говорю что С# получается не очень подходит для DDD

сделать можно всё, спору нет

но тогда и на С++ можно всё сделать

ну вот это я и имею в виду, когда говорю что С# получается не очень подходит для DDD

Здесь С# вообще не причем, если что.

Тут речь шла про то, как типобезопасно описывать Id.

нене, речь изначально шла о фичах c#

которые асимптотически приближаются к f#

но никак не приблизятся )

с айди это лишь один из примеров

нене, речь изначально шла о фичах c#

Ну я видимо это пропустил. Я пришел к тому моменту, когда шла речь уже про Id. И, имхо, это как раз тот случай, когда важно, чтобы описанный код обобщался и твой вариант под это не попадает.

не понимаю этот момент с обобщением. Мой вариант - попытка заменить летающие кругом примитивные типы int, string, long на что-то осмысленное и запрячь компилер помогать мне

обобщение тут каким боком?

не понимаю этот момент с обобщением. Мой вариант - попытка заменить летающие кругом примитивные типы int, string, long на что-то осмысленное и запрячь компилер помогать мне

Ну Id<'a> - это точно такой же вариант с заменой, только он обьявляется один раз и легче позволяет писать код, который будет работать с id любой сущности.

да почему именно Id? я ж уже писал что это частный случай. Что делать с приходящими из базы почтовыми индексами например? это не Id

или вид shareClass финансового фонда? это стринг, но я не хотел бы случайно подать туда имя юзера

да почему именно Id? я ж уже писал что это частный случай. Что делать с приходящими из базы почтовыми индексами например? это не Id

По-хорошему надо бы иметь библиотеку типа вот такой: https://github.com/fthomas/refined Но я не знаю, есть ли аналог для F#

А, хм, если смотреть пример с Id<TEntity, TId>, то я не знаю, как правильно объявлять поля-ключи от других сущностей :(

В чем проблема? Непонятно, как залать верный тип Id?

По-хорошему надо бы иметь библиотеку типа вот такой: https://github.com/fthomas/refined Но я не знаю, есть ли аналог для F#

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

В чем проблема? Непонятно, как залать верный тип Id?

в том что тебе надо TEntity какой-то ещё придумать

три класса там где это ненужно

В чем проблема? Непонятно, как залать верный тип Id?

Кажись, я понял по описанию товарищей выше.

в том что тебе надо TEntity какой-то ещё придумать

IEntity - один интерфейс там, где это нужно

в том что тебе надо TEntity какой-то ещё придумать

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

Штука в том, что айдишнику обычно не хватает типа сущности, на который он ссылается

Странно воспринимать его указание как недостаток

Косяк C# в том что приходится тип самого айдишника с собой таскать

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

я ещё в большем количестве приложений видел обычные инты и лонги, и всем норм )

ну, до первого непонятного бага в продакшене

ну, до первого непонятного бага в продакшене

Именно

я ещё в большем количестве приложений видел обычные инты и лонги, и всем норм )

Ну тут ничто не мешает добавить "маркерный" тип сущности, который будет только в Id<..> использоваться.

ну вот это и называтся "костыли"

Ну тут ничто не мешает добавить "маркерный" тип сущности, который будет только в Id<..> использоваться.

Можно и не маркерный :)

ну вот это и называтся "костыли"

Зато повторяющегося кода будет меньше, чем в твоем варианте.

И способности к обобщению больше.

ну вот это и называтся "костыли"

Костыли - это по типу на каждый Id городить

Костыли - это по типу на каждый Id городить

+

да всё можно. Можно даже зделат ьчтобы кругом летал тип Customer

надо говорить, чем это плохо?

надо говорить, чем это плохо?

Надо, если это только тип-параметр дженерика а не объект с данными

Надо, если это только тип-параметр дженерика а не объект с данными

https://blog.ndepend.com/marker-interface-isnt-pattern-good-idea/

https://blog.ndepend.com/marker-interface-isnt-pattern-good-idea/

Только это не маркерный интерфейс. Разные паттерны немного.

ну товарищ сказал за маркерный тип

либо я что-то не уловил?

почему не аттрибуты тогда уж?

либо я что-то не уловил?

Да, я сказал, что можно и не маркерный. Маркерные типы я не использую, если без них можно обойтись

ну товарищ сказал за маркерный тип

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

ну товарищ сказал за маркерный тип

А маркерный интерфейс - это абсолютно другой паттерн и тут про него никто не говорил

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

Я использую собственно тип-сущность как параметр. Если к нему по тем или иным причинам доступа нет - можно и маркерный.

наверное нужны примеры кода, иначе опять не понимаю

Id<Customer, int> - идентификатор заказчика в виде целого числа. Данных самого заказчика в нем нет, но где-то (обычно в специальном сервисе) по идентификатору их можно получить.

почему это именно тип, а не как обычно Id<ICustomer, int>

Можно и Id<ICustomer, int> - фишка в том, что на тип сущности ограничений нет. Главное, что тип-идентификатор содержит явное указание на то, какую именно сущность он идентифицирует.

При этом в рантайме - это самый обычный int без оверхеда

ну это по сути и есть один из видов markerInterface

ну это по сути и есть один из видов markerInterface

Нет. У тебя сущности типов не имеют?

У меня имеют - а значит их типы маркерными не являются по построению

почему нет. Какая ответственность у этого типа (или интерфейса)? только обозначить принадлежность чего-то к чему-то. Точно так же можно было написать class Id: Customer {} где customer - тип безничего

только то что его запихали в дженерик не меняет сути происходящего

почему нет. Какая ответственность у этого типа (или интерфейса)? только обозначить принадлежность чего-то к чему-то. Точно так же можно было написать class Id: Customer {} где customer - тип безничего

Нельзя. Твой тип Id будет наследником (или реализацией) чего-то одного. Мой - обобщенный.

Коллеги,вы ща так до комонад договоритесь

Нельзя. Твой тип Id будет наследником (или реализацией) чего-то одного. Мой - обобщенный.

поэтому всегда и делают ICustomer

и это... вуаля marker interface

почему нет. Какая ответственность у этого типа (или интерфейса)? только обозначить принадлежность чего-то к чему-то. Точно так же можно было написать class Id: Customer {} где customer - тип безничего

Ответственность очень простая - Id служит не просто числом или Guid, а идентификатором конкретной сущности. Сама сущность тоже имеет тип - маркеры остаются только у тех, кто для своих сущностей типов не создает.

Вот здесь можно посмотреть на NewType, NumType, FloatType. И вообще много чего приятного для функционального стиля на C#. Но все же это костыли. https://github.com/louthy/language-ext

Зачем нужны сущности без типов в ООП - ХЗ

только то что его запихали в дженерик не меняет сути происходящего

Принципиально меняет. Проблемы маркерных интерфейсов (если ты, конечно читал статью, которую сюда скинул) принципиально связаны именно с понятием интерфейса и его стандартными способами использования. А мы говорим про отдельно стоящий тип (который в идеале нужно сделать sealed), для которого это всё не актуально.

ну вот и получается огород с наследованием, sealed и прочими дровами

не нравится

f# one love ❤️

ну вот и получается огород с наследованием, sealed и прочими дровами

Где ты видишь наследование? Пока только у тебя на каждый Id создается отдельный тип. А типов сущностей якобы нет, хотя Id ссылается именно на сущность.

f# one love ❤️

Ага, только это же может спокойно сделать и в F#, язык тут вообще не причем.

зачем? зачем это спокойно делать в f# когдатам есть алгебраические типы?

не убедили вы меня, короч )

не убедили вы меня, короч )

А надо было?

f# one love ❤️

F# |> I❤️

зачем? зачем это спокойно делать в f# когдатам есть алгебраические типы?

Так чем тебе Id, который мы показывали не алгебраический тип?

очень шумно и геморно

Это тот же самый вариант, что у тебя, только обобщенный.

а так-то у микрософта есть такой вариант в архитектурном туториале

очень шумно и геморно

Тише, чем у тебя по типу Id на каждый тип сущности

вот официальный костыль от ms: https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/enumeration-classes-over-enum-types

чувство прекрасного СТРАДАЕТ

вот официальный костыль от ms: https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/enumeration-classes-over-enum-types

И какое отношение ЭТО имеет к типам Id?

господи, почему опять Id

такое ощущение что некоторые через строчку прыгают

речь шла об алгебраических типах

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