将Delphi 7数据访问移植到c#

这没有什么神奇的配方。我也是一名Delphi开发人员，现在在。net世界工作。

德尔福是极端的。每种语言都可能有写得好的或写得不好的软件。但在Delphi中，当一个应用程序写得很好时，它就是天堂。当它不是，它地狱。你们能明白我的心情Delphi将RAD带到了一个全新的水平。所以你可以非常快地编写软件。但它变得杂乱无章……有点像WinForms，如果你在按钮事件中写SQL Insert命令:)

这是我的想法:

• 当你使用。net时，请使用c#。不要回头看。
你一定要从数据层开始。
• 如果你现在要保留你的Delphi UI，并让它们与你的。net DAL一起工作，你甚至可能会惊讶自己不想改变到WinForms。有些人可能会对此感到不安，但时间会证明……
• 你可能想把你的DAL实现为WebServices。在你的软件的两个方面都有很多学习的机会。而且还有可重用性!
• 从头开始您的DAL。你不会后悔的。
• 不要从头开始UI。尝试使用现有的UI。UI需要时间。如果您要检查所有现有的屏幕，您将摆脱不良的东西，然后连接到新的。net DAL。但是从头开始构建一切是压倒性的，从长远来看可能会让团队感到沮丧。

您可以使用 Delphi棱镜。
它不是真正的Delphi，而是面向。net的Object Pascal。

然而，从Delphi移植到Prism将会容易得多，因为它是pascal的，而且Embarcadero已经努力使转换变得容易。

因为它使用。net而不是VCL，所以它是而不是一个简单的重新编译，但是你可以重用更多的东西，否则你会。

这看起来像是DataAbstract可以发挥作用的地方。它提供。net和Delphi支持(还有更多，Java已经在开发中)。

它将允许使用c#创建服务器并通过DA中间件连接Delphi客户端。

作为第一步，你的应用程序可以移动到一个基于 delphi的服务器和客户端，当C/S通信逻辑工作时，你可以用c#创建一个等效的服务器，然后切换。

注意，我并不是说这是一个好主意，只是表明技术上有一个直接的方法。抽象层和中间件的整体思想是在实际实现方面更加灵活。

我的处境非常相似。看到问题

我最初决定使用WCF，但是Delphi的WSDL导入器无法破解它，我现在使用ASP.net asmx web服务，互操作性得到了极大的改善。

我们正在应用分阶段的迁移，从具有不一致的内联SQL、存储过程和多达900 - 1200行方法的厚客户端迁移到多层解决方案。一旦服务器端功能就绪，我们将继续在Delphi客户端中实现更改。这允许现有的应用程序继续工作，并且测试和部署可以分阶段完成。

我从实现DAL开始，使用实体框架，我们将所有的数据表表示为实体，并使用每个实体的数据传输对象与客户端交换数据。

接下来业务逻辑将被迁移到各个功能区域，最后客户端，将简单地做客户端表单应该做的事情，允许用户与应用程序交互。

我们选择EF的主要原因之一是允许Visual studio自动生成delphi类，通过调整4个模板来进行更改跟踪(仍在进行中)和数据持久化逻辑。

仍然有一个障碍:在Delphi 2010中，来自。net web服务的客户端数据绑定仍然是不可能的。因此，我们将把这件事留到最后。

所有这些将使我们能够更快地实现定制的客户请求，而不破坏客户端设计。

对于那些问为什么，坚持它总是一个坏主意的人，请记住，在某些情况下(像我的)这些使用得很好的应用程序，是非常复杂的，并不是所有的Delphi开发人员仍然在为有问题的设计和编程决策辩护。当前，当变量具有多种含义时，添加新功能总是一场赌博，对于这种规模的应用程序，Delphi 2010 IDE已经不够了，从Visual Studio移植过来后，维护起来真的很麻烦。不要误解我的意思，我学习了Delphi来进行这个开发，但是这个历史产品的编写方式(在Delphi 5中)是完全不可持续的。

问题不在于为什么，而是在很多情况下:在被迫进行重大重写或放弃产品之前，你能承受忽视这个问题多久?

虽然我认为重写总是一个错误，但您不妨从任何技术试验开始的地方开始:制作原型。安装firebird ADO.net连接器，并使用c#编写您的DAL。

重写一个现有的应用程序总是比修复你当前的应用程序更多的工作。最后，你将失去可移植性，而不是获得它。

如果我要用别的东西重写一个Delphi应用程序，它甚至不是本机代码，它将是Java，而不是。net。即便如此，我还是要重复我的第一点;重写是浪费时间和金钱，而且在我所见过的任何现实世界的业务中，它们总是一个错误。然而，人们决定一次又一次地这样做。