Когда я разрабатываю модели для домена, они почти всегда имеют некоторую функциональность .IsSomething. IsNew и IsDirty являются общими для целей сохранения данных, IsValid для проверки бизнес-правил, даже IsFraudulent в текущем проекте (дополнительная проверка бизнес-правил) и т. Д. Всякий раз, когда я вижу, что они реализованы другими, они почти неизменно сделано так как методы. Но я задаюсь вопросом, есть ли конкретная причина для этого.
Я склонен видеть свойства как описание объекта, а методы - как выполнение какого-либо действия. Они действительно не выполняют действия. Они включают в себя код, потому что они динамически определяются при вызове, и они явно доступны только для чтения, но для меня они все еще подходят как свойства, а не методы.
Потенциально может быть проблема с сериализацией свойств. Хотя модель с расширенным доменом в любом случае имеет тенденцию к плохой сериализации, учитывая, что она содержит логику и функциональность, поэтому в любое время, когда мне нужно что-то переместить через границу службы, я обычно все равно сначала сплющиваю ее в определенную структуру DTO.
Но мне интересно, есть ли у кого-нибудь еще понимание этого вопроса? Есть ли веская причина для того, чтобы реализовать их как методы, а не как свойства?
(Тангенциально связанный, хотя ответ уже был дан , свойства расширения действительно помогли бы в согласованности чего-то подобного. У меня есть несколько IsSomething() методов расширения, обычно на System.String, для реализации предметно-ориентированной логики. Но даже если свойства - это путь, я могу придерживаться методов только для согласованности с расширениями.)