当我为域设计模型时,它们几乎总是.IsSomething在它们上面有一些功能. IsNew并且IsDirty对于数据持久性目的而言是常见的,IsValid对于业务规则验证,甚至IsFraudulent在当前项目中(更多业务规则验证)等.每当我看到其他人实现这些时,它们几乎总是作为方法完成.但我发现自己想知道是否有特殊原因.
我倾向于将属性描述为描述对象和方法以执行某种操作.这些并不是真正的行动.它们涉及代码,因为它们在被调用时是动态确定的,并且它们显然是只读的,但对我来说它们仍然适合作为属性而不是方法.
我想,可能存在属性的序列化问题.虽然丰富的域模型往往不能很好地序列化,因为它包含逻辑和功能,所以每当我需要在服务边界上移动某些东西时,我通常首先将它扁平化为定义的DTO结构.
但我想知道其他人是否对这个问题有任何见解？是否有充分的理由将这些实现为方法而不是属性？
(切向相关,虽然已经给出了答案,但扩展属性确实有助于在这样的事情上保持一致.我有许多IsSomething()扩展方法,通常System.String用于实现特定于域的逻辑.但即使属性是通过go,我可能想坚持使用方法只是为了与扩展保持一致.)
假设访问该属性:
然后我认为没有理由不把它变成财产.序列化不应该是一个问题 - 大多数序列化方案提供了将属性标记为瞬态(即不被序列化)的方法.
| 归档时间： |
|
| 查看次数： |
104 次 |
| 最近记录： |