Closed. This question is
off-topic。它当前不接受答案。
想改善这个问题吗？
Update the question，所以它是
on-topic，用于堆栈溢出。
已关闭8年。
我在C＃.NET中经验很少，但是在Delphi中有多年的经验。是否有任何Delphi + .NET人员可以为我提供一些指导？
这是独家新闻：
我将负责代码库的大修（200,000行以上）。我们将创建一个完整的n层架构，前端是Silverlight。根据我的研究，我们选择Silverlight作为前端是因为它可以轻松地部署在浏览器和应用程序中。
我无法在Remobjects SDK和WCF之间找到清晰的比较。我遇到的几个线程都提到了WCF的问题，例如响应时间，较大的开销和
somewhat snotty responses from MS。
这个问题更多的是后端。我们当前的代码库在Delphi中。如果有可能，是否有必要将后端保留在Delphi中？争论在于使用WCF（如果迁移到.NET）还是使用Remobjects SDK（同时使用.NET和Delphi风格）（如果坚持使用Delphi）。
Delphi后端+ Silverlight前端的优点：
现有的代码库：迁移过程中的时间更少
现有知识：熟悉我们代码库的开发人员已经熟悉Delphi
易于部署：单个exe / dll部署很难忽略！
Cadence：Remobjects SDK已经稳定多年
Delphi Remobjects SDK后端+ Silverlight + Remobjects SDK前端的缺点：
技术：Remobjects .NET甚至可以与具有Session功能的Remobjects Delphi通信吗？
知识：除了我们很少的开发人员以外，delphi的知识在我们所在的城市地区非常薄。
项目代码的重用：我们将需要重新开发C＃中的类以及在Silverlight中使用的Delphi。
费用：许可的额外费用
未来：很难说德尔福何时会崩溃
现在用于WCF .NET。
WCF .NET后端+ Silverlight前端的优点：
项目代码重用：可以在后端和前端中使用一个类
技术：已经证明
知识：我们的城市地区喜欢.NET，因此有很多人才可以招聘。
未来：每个人都知道MS可以从.NET和VS 2010中获得大量收益。这为.NET体系结构增加了一定的稳定性。
WCF .NET后端+ Silverlight前端的缺点：
现有的代码库：除了类结构引用之外，还需要重做我们的整个代码库。
部署：我本人还没有部署WCF应用程序，但是我知道它比Delphi更复杂。
Cadence：微软臭名昭著的是一旦行业稳定就改变游戏规则。发生在COM上，什么时候用于.NET？
理想的情况是什么？全部写完之后，由于成本较低且拥有稳定未来的可能性较高，因此看起来像C＃后端是赢家。我们现在使用的后端都是将来所有项目的选择方法。
您在实现WCF n层应用程序方面有什么经验？
在设计应用程序时，是否有任何清晰简洁的书/文章概述了WCF的用法以及最佳实践？
在这种情况下，有没有比WCF更好的解决方案？
摆脱你的想法！