Действительно ли это - хорошая практика для реализации логики в свойствах

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

Цитата из указанной выше статьи:

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

Обычно свойство влияет только на 1 переменная, так как она была сделана в основном для этой цели. Но иногда вам нужно свойство более высокого уровня, которое не является просто переменной 1 к 1. Так что в этом случае нормально, что он будет содержать код. Но вы должны помнить, что свойство не предназначено для использования как функция. Когда вы вызываете функцию, вы знаете, что она произведет некоторую обработку. Когда вы звоните в собственность, вы ожидаете, что это будет быстро.

Но, наконец, это вопрос предпочтений, и, как и в стандарте кодирования, следовать тому, что говорит вам начальник, остается на ваше усмотрение. Так что это неплохо и зависит от вашего суждения.

Вполне нормально иметь некоторую логику в свойствах. Например, проверка аргументов в сеттерах и ленивые вычисления в геттерах - довольно распространенные явления.

Однако обычно это плохая идея для доступа к свойству, чтобы сделать что-то дорогое, например, вызов базы данных. Разработчики склонны считать, что свойства достаточно дешевы для оценки.

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

Здесь применим общий ответ: It Depends.

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

Однако логика отслеживания состояния и другая домашняя работа часто находится в свойствах. Например, сущности Entity Framework 4, отслеживающие себя, имеют логику управления состоянием в каждом примитивном сеттере свойства, чтобы обеспечить возможность отслеживания.

Альтернативой логике в свойствах является аспектно-ориентированное программирование (AOP). Используя AOP, вы можете "внедрить" логику между объектами и процессом хостинга. Доступ к объектам может быть "перехвачен" и обработан условно.

На мой взгляд, бизнес-логика допустима в Setter/Getter только в определенных ситуациях. Например: разрешено помещать логику, которая отвечает за проверку входных данных, потому что сеттеры отвечают за поддержание состояния объекта, и это состояние не должно быть нарушено. Поэтому вы должны сократить эту бизнес-логику до небольшой части кода, которая отвечает только за один объект.

Другое дело, что ваш класс должен быть (в лучшей ситуации) POCO. Почему? Потому что он должен быть многоразовым, а когда класс содержит логику в Свойствах, многоразовость может быть просто заблокирована. Подумайте, что у вас есть SqlServerPerson с некоторой валидацией SQLServer в свойствах, тогда может быть трудно заменить его, например, на NHibernatePerson, когда вы измените доступ к ORM/DB.