В общем, я бы не рекомендовал структуры для бизнес-объектов. Несмотря на то, что вы МОЖЕТЕ получить небольшую производительность, двигаясь в этом направлении, когда вы работаете в стеке, вы в конечном итоге ограничиваете себя, и конструктор по умолчанию может быть проблемой в некоторых случаях.
Я бы сказал, что это еще более важно, если у вас есть программное обеспечение, которое публикуется для общественности.
Структуры подходят для простых типов, поэтому вы видите, что Microsoft использует структуры для большинства типов данных. Аналогичным образом структуры подходят для объектов, которые имеют смысл в стеке. Структура Point, упомянутая в одном из ответов, является хорошим примером.
Как мне решить? Обычно я по умолчанию возражаю против объекта, и, если кажется, что это что-то, что выиграло бы от использования структуры, которая, как правило, была бы довольно простым объектом, который содержит только простые типы, реализованные в виде структур, то я обдумаю это и определю, чувство.
Вы упоминаете адрес в качестве примера. Давайте рассмотрим один, как класс.
public class Address
{
public string AddressLine1 { get; set; }
public string AddressLine2 { get; set; }
public string City { get; set; }
public string State { get; set; }
public string PostalCode { get; set; }
}
Продумайте этот объект как структуру. При рассмотрении рассмотрим типы, включенные в этот адрес, «struct», если вы закодировали его таким образом. Вы видите что-нибудь, что может не сработать так, как вы хотите? Рассмотрим потенциальную выгоду производительности (то есть, есть ли она)?