Выбор сущности / значения объекта - PullRequest
0 голосов
/ 27 апреля 2009

В дизайне, управляемом доменом, общеизвестно, что объект с идентичностью является сущностью. Например, любой человек будет иметь несколько форм личности (имя и т. Д.).

Но ценностные объекты - это объекты без идентичности. Одним из объектов общего значения является адрес, однако адрес не имеет идентификатора. Но на уровне базы данных у нас может быть составной ключ. Эта концепция работает в DDD? Это сделало бы адрес идентифицируемым комбинацией названия дороги, почтового индекса и номера двери (пропуская информацию, такую ​​как город и город). Деньги были бы другим ценным объектом.

Различие, по-видимому, заключается в объектах без единого идентифицируемого поля, а объекты-значения обычно не принадлежат сущности. Например, «я» (заменить на мое имя) может носить обувь и т. Д., Но «я» - это не обувь, рубашка и т. Д. (http://www.lostechies.com/blogs/joe_ocampo/archive/2007/04/23/a-discussion-on-domain-driven-design-value-objects.aspx).

Это правильный способ думать о вещах? Кроме того, с этим менталитетом / подходом, я могу применить это к выбору значения / ссылочного типа в C #. Я могу также пойти с подходом DDD все же?

Спасибо

1 Ответ

0 голосов
/ 27 апреля 2009

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

Ключевое различие между значением и ссылочным типом заключается в том, что типы значений копируются при передаче в метод. Это означает, что они с большей вероятностью будут сидеть в стеке, а не в куче, и их обход обходится дороже; как таковой размер становится фактором для рассмотрения. Рекомендуется, чтобы структура была размером не более 16 байт (внизу примечаний здесь ) и имела комплексную структуру адресов (номер дома, название дома, район улицы, город, страна и т. Д.) легко сломать это.

Тем не менее, семантика entity: value :: class: struct очень похожа, и я вижу много преимуществ от моделирования данных таким способом (два человека, которые живут по одному и тому же адресу, не поделиться этим адресом, так как изменение адреса одного человека не должно менять адрес другого. Таким образом, наличие адреса в качестве структуры приведет к такому разделению. При этом все экземпляры лица в приложении должны указывать на одного и того же человека). Но есть соображения производительности и памяти. Возможно, неизменяемые классы подойдут для этих типов значений?

Подводя итог: Различие между сущностью и значением в DDD основано на том, что представляет собой объект. Код должен основываться на том, что вы собираетесь с ним делать.

...