Структуры классов Vs в .NET Business Layer

Question

Я сейчас застрял в «продвинутом» классе ASP.NET, и мой инструктор только что высказал мнение, о котором я не уверен. (Я говорю «продвинутый», потому что он по-прежнему использует HTML-таблицы для макета страницы, и мы просто говорили о невероятно продвинутой теме «Мастер-страницы». Мне нужен глазной отбеливатель!)

Он утверждает, что вместо, скажем, создания класса Person который содержит все применимые данные и методы, вы должны создать как класс Person, так и класс Person. Структура содержит то, что обычно является свойствами класса Person, а класс содержит только методы. Поскольку структура Person находится в стеке, данные, связанные с вашим человеком, уходят, как только ваш метод или что-то выскочит из стека, а не мусор, собранный в кучу, как с объектом.

Предполагается сохранить память и ускорить процесс сбора мусора.

Вопрос: насколько большой эффект может это произвести и действительно ли это стоит?

Answer 1

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

Во-первых, Структуры не всегда, выделенные на стек. Они выделяются только в стеке, когда параметры или локальные экземпляры внутри метода. Структурой, которая определена как член класса, на самом деле выделена куча. Таким образом, аргумент о том, что структура более эффективен из-за сокращения усилий для сбора мусора, справедлив только в определенных узких контекстах.

Во-вторых, любые члены класса, не относящиеся к ValueType, также выделяются на кучу (например, строки). Таким образом, даже если структура может быть просто удалена из стека, любые объекты кучи, которые она ссылается, все равно должны быть собраны в мусор.

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

---

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

Кроме того, конкретный случай использования структуры как объекта DTO кажется ошибочным, поскольку он вводит излишнюю избыточность. Поскольку structs не может наследовать другие структуры, вы не можете выразить is-a отношения. Что вы делаете, когда у вас есть Клиент, который наследует от Лица. Повторяете ли вы все свойства Person в структуре Customer? Вы встраиваете структуру Person внутри структуры Customer? Ни один подход не идеален. Если вы, по крайней мере, использовали классы, вы могли бы продлить действие Клиентом.

Answer 2

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

Похоже, ваш профессор выступает за использование data transfer objects, что будет способствовать разделению состояния и поведения. Это может быть хорошим дизайном, если все сделано правильно (и в большинстве случаев вы реализуете этот шаблон, используя классы, а не структуры).

Причина, по которой я говорю, что использование структуры может быть более опасным, - это то, что типы значений обрабатываются CLR более по-разному, и если они плохо написаны (например, измененная структура), могут создавать ужасные головные боли. Кроме того, если ваш тип содержит много полей, а затем передается от метода к методу, вы будете копировать значение каждого поля в каждом вызове метода, тем самым используя больше памяти, чем если бы вы использовали класс в первую очередь.

Answer 3

Честно говоря, я впервые услышал об этом подходе.

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

MSDN, where Microsoft has published structure design guidelines.

Классы, как ваш инструктор говорит о воле легко простираться мимо правила 16 байт. И трудно увидеть структуру такого рода, не инкапсулирующую бизнес-(или, по крайней мере, проверку) правила в свойствах. На мой взгляд, это был бы довольно дрянной дизайн.

Answer 4

Проблема с этим подходом заключается в том, что объекты (экземпляры классов) имеют изменяемое состояние. Структуры в противоположность должны быть неизменными, то есть они не имеют состояния, которое можно изменить. В типичном приложении бизнес-уровень в значительной степени использует изменение состояния объекта (т. Е. Рабочих процессов, проверки и т. Д.).

Преимущества, которые он описывает, не оправдывают недостатков, которые это принесет.

Answer 5

Это звучит довольно глупо для меня. Я не уверен, сколько запасов я бы поставил в кодировании совета того, кто использует таблицы для размещения в HTML. Если бы это была техника, которая принесла значительные преимущества, это была бы стандартная практика. Это не так. Это первый раз, когда я слышал об этой технике.