Pull to refresh

Comments 26

Может глупый вопрос, но зачем вам нужно именно это наследование? Вот вы выделили Contractor, и у него есть тип. Так зачем же наследоваться? Почему нельзя сделать отдельные контексты для каждого типа, которые можно получить из специального сервиса?
На контрактор стоят foreign keys из нескольких других таблиц. Без базового класса нельзя поставить foreign keys на любого «контрагента», потому что они хранятся в разных таблицах, потому что у них разный набор обязательных к заполнению атрибутов.
Так я не против базового класса. Я просто за то, что бы заменить механизм наследования, на механизм получения нужных контекстов.
lailore:
Так я не против базового класса. Я просто за то, что бы заменить механизм наследования, на механизм получения нужных контекстов.


Что имеется ввиду под получением контекстов? DDD bounded context?

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


P.S. Это даже не привязываясь к хранению в РСУБД вообще и обеспечению ссылочной целостности малой кровью.

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

Лучше выделять контексты по нужде. Например, если в рамках контекста договоров нам нужно иметь физлиц не только в качестве контрагентов, но и в качестве своих сотрудников, то имеет смысл рассмотрение выделения физлиц в отдельный контекст или хотя бы агрегат с хранением в контексте договоров в сущностях "контрагент-физлицо" и "сотрудник" скалярных идентификаторов сущности "физлицо" из нового контекста/агрегата. С одной стороны избежим дублирования сущностей, с другой простота манипулирования объектным свойством "контрагент" для сущности "договор" останется.

Да, ИП портят стройную картину мироздания.

Во второй части, с tpt, обойдены вниманием юрлица иностранных государств, физлица иностранных государств, граждане с видом на жительство…
Нам они не очень нужны, поэтому не разбирались. Подход позволяет создать по наследнику на каждого такого «контрагента» и добавить необходимые свойства.
При появлении новых наследников, баланс плюсов/минусов подхода может поменяться. Необязательно в худшую сторону.
Притом даже очень сильно, т.к. в одной ипостаси физлицо как ИП может приобретать кофе для своего офиса, а в другой — тот же кофе домой…

Делаем ИП наследником физлица, возможно с каким-то общим интерфейсом (или тупо копипастой) с юрлицами, и дело в шляпе. Портят они сильно жизнь когда их пытаются вынести в отдельную категорию, или в подкатегорию юрлиц.

Ну да — то бишь выращиваем особенную такую морскую свинку, которая не хрюкает и плавает не очень -)

Это законодатели вырастили, а мы лишь моделируем :) В некоторых юрисдикциях подобного понятия нет или его контрагентов оно не касается, им безразлично приобретает физлицо что-то для личного потребления или для предпринимательской деятельности без образования юрлица — это исключительно проблемы его и государства.

Ну так или иначе — маркетологи хотят выделять их в отдельную сущность, они сами хотят документы уровня юрлица ибо УСН15% подразумевает подтвержденные расходы, юристы — туда же — есть тонкие различия в трактовании ЗОЗПП…

И это в случае отношений в одну сторону, а когда еще и обратно в виде получения услуг или товаров от физиков, юриков и ИП — там свои нюансы.

p/s/ возможно скоро еще выделятся в отдельную сущность — самозанятые граждане =)
Все зависит от сложности логики в конкретной организации на стороне юрлиц и физлиц.
Если акцент на юриков, может получиться, что проще отнаследоваться от юрлица, и недостающее откопипастить с физиков.

Да, есть еще traits. Но и они не панацея.

И у наследования ИП от физика свои минусы. Насколько я понимаю, при наследовании от физлица, запись по ИП содержит только уникальные для ИП атрибуты, а фио и прочее на физике.
Как с точки зрения БД отличить покупку Васи от покупки ИП Васи? На сущности Покупка у атрибута Покупатель будет одиковый ID в обоих случаях.

Угу. В том числе и такое… Слегка коряво, но зачастую применимо — представители/доверенные лица: тогда живет ИП как отдельная сущность и живет физик, который может быть представителем ИП имени самого себя…

Решение в лоб — для Васи запись в таблице "контагенты" с типом "контрагент-физлицо", для ИП Васи — "контрагент-физлицо-ИП" с дублированием персональных данных. Более сложное создание сущности "физлицо" на которое будут ссылаться "контрагент-физлицо" и "контрагент-физлицо-ИП" и, вероятно, "контрагент-юрлицо" в полях типа "гендир", "главбух", и даже "сотрудники".

Второй вариант реализован, например, в 1C. Отдельно справочник физ.лиц, на который ссылаются сотрудники и контрагенты — «физики».

А чем поведение всех этих типов отличается? Вы нам показали 3-4 abstract data type, которые отличаются только данными, но не поведением в контексте задачи.


Почему вообще кому-то надо знать детали того, что у организации есть атрибут1, а у физлица — атрибут2? Почему всех контрагентов нельзя подвести под единый интерфейс а-ля IContactSigner с одним методом sign(IContract contract)?

Как минимум могут (или даже должны) отличаться формы договоров. В одном, "и ФИО, одни реквизиты", в другом "и название, другие реквизиты, в лице ФИО, третьи реквизиты, действующего на основании четвертые реквизиты"

Мысль здесь в том, что систему определяет поведение, а не структура данных предметной области или, что еще веселее, способ хранения этих данных. В данном случае, судя по всему, говорили «ООП», а имели в виду «РСУБД». Тех же контрагентов можно было бы лепить билдером, а разницу в формировании контрактов представить стратегиями. В результате избавились бы от этого странного искусственного наследования.

Да лепить можно чем угодно, главное что в предметной области это разные подтипы одного типа "контрагент". Собственно особо вариантов нет, по-моему — или "суперконтрагент", включающий все свойства всех подтипов, а также свойство подтипа, или наследование. Какие-то другие варинты, что в голову приходят будут лишь разновидностью одного или другого. А как на базу маппить дело десятое. Хорошо, если ссылочную целостность можно обеспечить внешним ключом, а нет — так и бог с ним. Может она и не нужна вовсе.

Мы так и сделали, только у нас появилось свойство Signature { get;} у контрагента. Это свойство ушло в IContractor. Но, если бы общего поведения не было, то сделали бы pattern matching по всем наследникам.

Я акцентировал внимание на том, что версия:
    public virtual LegalContact LegalContact { get; set; }

    public virtual PersonContact PersonContact { get; set; }

была хуже финального варианта с точки зрения хранения данных
Sign up to leave a comment.

Articles