可能重复:
您何时使用"this"关键字？
我刚刚开始使用Resharper来分析我的代码,它有很多建议我做的事情,我对它的输出非常满意,因为它也教会了我一些更好的做法.
显然,它的建议可以被忽略,其中一个我想从社区获得一些反馈!
我总是倾向于将'this'限定符用于属于当前类的属性(即this.Name).没有真正的理由 - 我似乎只是采用了这么多个月.
Resharper建议这是多余的,也许我应该删除它.
你怎么看？
这不是一个问题,但我对问题的答案我无法在互联网上找到解决方案.
我在MVVM Silverlight应用程序中清除SearchText时遇到问题.我可以清除SelectedItem和Text,但是SearchText被遗忘了.它是只读的,不能通过绑定更改.
示例:带有国家/地区列表的AutoCompleteBox.当用户想要进入澳大利亚时,他们进入'au'此时该列表与奥地利和澳大利亚一起出现.然后用户可以选择澳大利亚并继续前进.在编辑结束时,他们点击"保存"按钮.此时,您可能希望清除数据以输入新数据.
即使您绑定了SelectedItem和Text属性,并将它们分别设置为'null'和string.Empty,SearchText属性仍然存在,AutoCompleteBox将不会清除,但将包含'au'.
我似乎还记得上一份工作中的一段时间我在他们的持续集成服务中使用的是带有CCTray的Cruise Control通知.
当构建失败时,会向最近签入代码的可能候选人发送通知(显示在通知托盘中).然后可以点击通知并"志愿者"来修复构建.然后,新的通知会自动发送给之前的收件人,以便知道有人在案件中.
我想知道这种功能是否在TFS中.
目前我们在TFS中使用自动电子邮件来实现第一部分(失败构建的通知),但如果可以自愿并向"失败候选人"发送自动回复(或其他内容),那将非常有用.列表,以便知道失败的构建正在被修复的过程中.
每当我观看有关实体框架的演示时,演示者只需设置一些表并使用自动创建的代码存根执行插入,更新和删除,但从不显示任何存储过程的使用.在我看来,这是从客户端执行SQL.
根据我的经验,这不是特别好的做法,所以我假设我对实体框架的理解是错误的.
类似地,WCF RIA Services演示使用EF,并且演示总是相同的.任何人都可以了解如何在典型的业务层/数据访问层/存储过程中使用EF.
我觉得我很困惑,不应该!!