如果数据库触发器是邪恶的，那么在 java 或 C# 中设置属性时产生副作用是否也是邪恶的？
Let's assume that [database triggers are evil].1
Does this mean that side effects when setting a property on a java or C# object are also evil?
It seems to me that all the same problems exist.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这里违背了规律......
属性不应该触发副作用。这就是方法的用途。
通过让属性产生副作用，您最终会陷入代码本质上被隐藏的情况。人们很少期望财产会启动某些流程或导致其他事情发生变化。如果必须记录下来，那么它并不明显并且容易被忽略。
然而，我们确实期望当我们调用方法时会发生一些事情。
以@astander 为例，他说更改“价格”的行为应该会导致不同的属性“成本”发生变化。但是，如果我们稍后添加一个名为“Discount”的新属性怎么办？ Price 和 Amount 属性周围的代码必须更改。这不太容易被发现。
然而，如果成本自行计算……那么一切都会变得更好。
Going against the grain here...
Properties should NOT trigger side effects. That's what Method's are for.
By having properties cause side effects you end up in a situation were code is essentially hidden. People rarely expect properties to kick off some process or cause something else to flip. If this has to be documented, then its not obvious and subject to being ignored.
However, we do expect something to happen when we call a Method.
Taking @astander's example, he says that the act of changing "Price" should cause a different property "Cost" to change. However, what if we later add a new property called "Discount"? The code around the Price and Amount properties would have to change. Which isn't very discoverable.
However, if Cost calculated itself.. then everything is better off.
不一定，不是。如果您有
Price或Amount属性，并且您对其进行了更改，那么Cost似乎也应该相应更改？或者您对这篇文章有什么不同的想法吗？
Not necessarily, no. If you have a
PriceorAmountproperty, and you change that, it would seem that theCostshould change accordingly?Or is there something different you had in mind with this post?
不会。许多特性可以而且应该引发副作用。
例如：想象两个视觉元素，其中子元素包含在父元素中。设置parent.Visible = false可能也应该设置child.Visible = false。
通常，这些副作用是通过事件（System.Windows.Forms 充满了 PropertyChanged 事件）或接口（例如 INotifyPropertyChanged）来明确显示的。
No. Many properties can and should trigger side effects.
Ex: Imagine two visual elements where a child is contained within a parent. Setting parent.Visible = false should probably also set child.Visible = false.
Often these side effects are made explicit via an event (System.Windows.Forms is full of PropertyChanged events) or an interface (such as INotifyPropertyChanged).
尽管属性有时很有用，但它们确实在团队环境中的日常编码中引入了一些不确定性，在团队环境中，并非每个人都必须以相同的方式解释属性的目的和适当使用。
这是出现的众多问题之一：
最终，我认为只要记录任何副作用或可能成本高昂的操作，上述两点就没有那么重要，因为这也应该适用于方法。
您可以安全地做出的假设越多，代码的复杂性就越低，但这种收益在某种程度上会被额外的通信开销所抵消。只有当团队中的每个人都在同一页面上并且保持在同一页面上时，它才有效。
有时我认为财产造成的问题比它们解决的问题还要多。
As useful as properties sometimes are, they do introduce some uncertainties in day-to-day coding in a team environment, where not everybody necessarily interprets the purpose and appropriate use of properties in the same way.
This is one of a number of issues that arise:
Ultimately, I think that the above 2 points don't matter that much so long as any side-effects or potentially costly operations are documented, because the same should apply to methods as well.
The more assumptions you can safely make decrease code complexity, but that gain is negated to some degree by additional communication overheads. It only works as long as everybody in the team is on the same page, and stays on the same page.
Sometimes I think properties cause more issues than they solve.
这要看情况。当然，会有一些副作用，这会让用户感到惊讶，在我看来，最好避免这些副作用。
我更喜欢属性的行为与字段非常相似，因为从读者的角度来看它们看起来是一样的（无论如何在 C# 中）。如果一个属性有任何不明显的副作用，我更喜欢方法而不是属性。
That depends. Certainly there are side effects, that will take the user by surprise and it is best to avoid those IMO.
I prefer that properties behave very much like fields, since they look the same from the reader's point of view (in C# anyway). If a property would have any non-obvious side effect, I would prefer a method over a property.
除了上面克里斯的评论之外（我确实同意），还有另一个方面导致触发器被认为有点不正当，那就是它们并不明显。
这使得很容易忘记，进而使它们很难调试。
人们（我是其中之一，而且肯定不是唯一一个）花费了数小时尝试调试问题并从头到尾检查整个流程（明显的结束，即数据库过程/DML 查询），以了解导致问题的原因是触发器 - 因为它们本质上是后台操作。
您还可能会争辩说，正确记录触发器应该可以轻松避免此类问题，但通常日志记录永远不会在数据库层本身中完成，因此使故障排除方面变得更加复杂。
In additions to Chris's comments above, which I do agree with there is another aspect that has contributed to triggers being considered a bit devious and that is the fact that they are non - obvious.
This makes then very easy to forget which in turn makes them very difficult to debug.
People (and i am one of them and not the only one for sure) have spent hours trying to debug issues and going through the flow start to end (apparent end i.e database procedures / DML queries) to realise what was causing the problem all along were the triggers - because of them inherently being background operations.
You could also argue that proper logging of triggers should result in easy avoidance of this kind of issue but usually logging is never done in the Database layer itself hence complicating this aspect of troubleshooting a bit more.