小编Jas*_*aty的帖子

应该StringBuilder.Capacity设置为最大.NET字符数,而不考虑空终止,或者在使用P/Invoke时,必须将其设置为更高,以便为空终止符保留空间.

自然的反应是它应该设置得更高,但似乎P/Invoke应该自动补偿.事实上,这实际上是在这里记录的:http://msdn.microsoft.com/en-US/library/s9ts558h(v = VS.100).aspx

这个问题的原因是大多数示例与上述文档并不严格一致.它们几乎总是被编码:

StringBuilder sb = new StringBuilder(dotNetChars + 1);
SomeWindowsAPI(sb, sb.Capacity);

代替:

StringBuilder sb = new StringBuilder(dotNetChars);
SomeWindowsAPI(sb, sb.Capacity + 1);

(我意识到一些API处理缓冲区大小参数的方式不同.假设API处理这是必须的常见方式,如GetFullPathName:http://msdn.microsoft.com/en-us/library/aa364963(v = VS.85) .aspx)

sb.Capacity直接在API调用中使用表达式似乎是避免不匹配的最佳实践.问题是添加+1是否正确.

环视四周.您可能会发现唯一显示的sb.Capacity + 1是MSDN文档.

当然,人们可以在谨慎的情况下使用比绝对必要的更大的缓冲区来分配,但我想知道如何做到这一点的共识.

通常需要将来自一个数据库中的主表的数据同步到其他数据库中的克隆表,通常是在其他服务器上.例如,考虑后端系统管理库存数据并且最终必须将库存数据推送到属于网站应用程序的一个或多个数据库的情况.

后端系统中的源数据严格标准化,具有数十个表和外键约束.它是一个精心设计的OLTP RDBMS系统.许多表中包含数百万行.需要定期将这些数据推送到其他数据库.尽可能频繁; 可以容忍延迟.最重要的是,后端和远程数据库的最大正常运行时间是必不可少的.

我正在使用SQL Server,熟悉更改跟踪,rowversion,触发器等.我知道微软会为这些场景大量推送复制,SyncFx和SSIS.但是,供应商白皮书和概述推荐技术以及解决方案的实际实施,部署和维护之间存在很大差异.在SQL Server世界中,复制通常被视为交钥匙解决方案,但我正在尝试探索替代解决方案.(有些人担心复制难以管理,难以更改架构,并且如果需要重新初始化,关键系统的停机时间会很长.)

有很多陷阱.由于大量表之间存在复杂的外键关系,因此确定执行捕获或应用更新的顺序并非易事.由于唯一索引,两行可能会以这样的方式互锁,即一次一行更新甚至不起作用(需要在最终更新之前对每一行执行中间更新).这些不一定是show-stoppers,因为唯一索引通常可以更改为常规索引,并且可以禁用外键(尽管禁用外键是非常不合需要的).通常,您会听到"只是"使用SQL 2008更改跟踪和SSIS或SyncFx.这些答案实际上并不符合实际困难.(当然,客户真的很难理解如何复制数据如此困难,使情况变得更糟!)

这个问题最终非常通用:执行许多重度相关的数据库表的单向同步.几乎每个参与数据库的人都必须处理这类问题.白皮书是常见的,实用的专业知识很难找到.我们知道这可能是一个难题,但工作必须完成.让我们来听听对你有用的东西(以及要避免的东西).告诉您使用Microsoft产品或其他供应商的产品的经验.但是,如果你个人没有对大量严重相关的表和行进行战斗测试,请不要回答.让我们保持这种实际 - 不是理论上的.

众所周知如何创建"契约优先"WCF服务,其中第一步是定义ServiceContracts和DataContracts.

如果一个人拥有"架构优先",那么如何进行WCF开发.换句话说,XSD架构已经独立开发.该服务可能不会偏离已定义的架构.作为一个复杂的问题,架构可能会使用无法转换DataContract的DataContract功能(毕竟功能非常小).

使用XDocument在服务器或客户端对整个文档会被罚款和良好的.(XDocument对于任何涉及XmlSerializer不幸的事情似乎已经失宠而没有替换的任何事情的使用将是非常优选的).要求元数据/ WSDL正确地报告每个标准的实际模式.它可能不会报告"通用"架构,例如xsd:any.(弄清楚如何处理这些WSDL要求是给我带来最多麻烦的部分.)

(这里的类似问题/答案没有解决XDocument或WSDL要求.)

如何递归处理路径,以便在处理完成后,路径下没有空目录.

例如,假设我们有,C:\Dir1\Dir2\Dir3并且这些目录中没有任何文件.结果应该是删除所有三个目录.

我想在不使用自定义任务的情况下完成此任务.

我注意到很多关于COM的书籍等都指出，在COM聚合中实现一个可以用作内部对象的对象相对容易。但是，除非我遗漏了一些东西，否则聚合似乎只能在极其有限的场景中成功，因此只有在明确认识到这种场景时才应提供对它的支持。

困扰我的部分如下。COM 聚合将内部对象的标识与外部对象的标识组合在一起。外部对象的实现者选择内部对象接口的子集，并将对这些接口的请求转发给内部对象。内部对象将所有对接口的请求转发到外部对象。现在假设内部对象作为其实现的一部分构造子 COM 对象。据推测，一个接口指针被传递给该 COM 对象，以便它可以与其父对象进行通信。内部对象对其实现的接口有一些了解。然而，外部对象可能选择不转发其中一些接口。事实上，文档指出外部对象不应盲目转发接口。这似乎意味着内部对象通常不能将接口指针传递给其他 COM 对象，除非特别要求外部对象将所有这些接口转发给内部对象。这不限于子对象场景。实际上，内部对象实现传递接口指针的任何地方似乎都可能受到影响。

因此，聚合似乎不是通用目的，因为——在内部对象必须与其他 COM 对象通信的情况下——它对外部对象提出了严格的要求，即必须最少转发哪些接口，并且不能将更多接口添加到这个列表在内部对象的未来版本中不会破坏与不转发这些接口的现有外部对象的兼容性。

这是对事物实际情况的正确（并且很少被记录）描述还是故事有更多内容？

我想检测(最好通过一个事件)什么时候添加,更改等任何内容FlowDocument,当它出现时我想让FlowDocumentScrollViewer显示FlowDocument自动滚动到结尾.

我想编写一个在ASP.NET和独立应用程序中工作的类库.在ASP.NET下运行时,需要在行为上有一些差异.检查库是否在ASP.NET应用程序中运行的推荐方法是什么？

我可以检查HttpContext.Current,因为它似乎在不在ASP.NET下运行时可靠地返回null.但是,当在ASP.NET中的后台线程上运行时,它也返回null.

任何意见HttpContext.Current或其他解决方案？

补充:感谢关于如何实现关注点分离的所有建议.但是,我想补充一点,这个库不会用于通用目的,所以对于我的特殊情况我不需要很大的灵活性.在我看来,到目前为止最好的(在这个线程中没有提到)是检查 HttpRuntime.AppDomainAppId静态为null,因为它似乎工作正常,即使对于ASP.NET后台线程.但是,这里提供的各种解决方案肯定会对有更多一般需求的其他人有所帮助.