У меня странный вопрос, который я изо всех сил пытаюсь понять, где в бизнес-модели находится конкретная логика. В частности, в свойстве POCO только для получения, которое возвращает значение, оцененное по отношению ко всем другим экземплярам в существовании того же объекта класса.
Например, скажем, у меня есть класс POCO "foo" со свойством get / set, которое называется "Value", тип валюты. Затем другое свойство в «foo» с именем «Percentile», которое представляет собой простой метод получения, типа int, с формулой, предназначенной для возврата конкретного экземпляра процентиля foo по отношению ко всем экземплярам Foo, существующим в системе.
Аналогичным сценарием может быть сценарий класса Document, где экземпляр Document может логически «знать» свой собственный статус по отношению ко всем другим документам в системе. Например. Определенный документ в серии может возвращать IsLatest = true, тогда как все другие экземпляры в этой серии возвращают false. Затем, если другой пользователь добавит новый документ, после переопределения свойства значение true в этом первом экземпляре будет повторно оценено как false.
Мне кажется, что это законная / разумная бизнес-логика, которую нужно моделировать и рассчитывать на лету из таблиц временной базы данных без необходимости постоянно обновлять / поддерживать эти значения в постоянном хранилище.
Но я думаю, что то, как я к нему подхожу, пахнет плохо, потому что это только приводит к тому, что моим отдельным экземплярам нужно знать обо всех других экземплярах, хранящихся в памяти, или иметь возможность выполнять запросы к постоянному хранилищу лениво всякий раз, когда рассматриваемое свойство опрашивается.
Должно быть более элегантное решение или подход к этой проблеме?
Как мне подходить к обработке коллекций POCO, где коллекция влияет на некоторые вычисляемые свойства в ее членах ??