我有一个奇怪的问题，我正在努力寻找一个关于在业务模型中何处容纳某种特定逻辑的问题。具体而言，在POCO仅限吸气剂属性中，该属性返回一个值，该值是相对于存在相同类对象的所有其他实例评估的。
例如，假设我有一个POCO类“ foo”，其具有名为“ Value”的获取/设置属性，请键入currency。然后，在“ foo”中的另一个名为“ Percentile”的属性，它是一个简单的getter，类型为int，其公式旨在返回与系统中存在的Foo的所有实例有关的foo百分位数的特定实例。 >
一个类似的场景可能是Document类的场景，在这个场景中，Document实例可以相对于系统中的所有其他文档在逻辑上“知道”它自己的Status。例如。系列中的某个特定Document能够返回IsLatest = true，而该系列中的所有其他实例都返回false。然后，如果另一个用户添加了一个新文档，则在对该属性进行重新轮询后，该第一个实例的true将重新评估为false。
在我看来，这是合法/合理的业务逻辑，需要从时态数据库表中进行建模和动态计算，而不必在持久性存储中不断更新/维护这些值。
但是我认为我的处理方式闻起来很不好，因为它只会导致我的单个实例需要了解内存中保存的所有其他实例，或者每当有问题的财产被轮询。
对于此问题必须有更优雅的解决方案或方法吗？
我应该如何处理POCO的集合，其中该集合会影响其成员中某些计算出的属性？