logo标签列表

将Delphi 7数据访问迁移到C#端口

c#delphidata-access-layersoftware-design
3
我们有一个用Delphi 7编写的客户端/服务器应用程序，后端数据库是Firebird。代码最初使用了数据访问层，但很快就变成了在表单和不同单元中分散的数据访问。
我们希望在不久的将来转向.NET，我认为最好的开始是先将DAL移动到.NET，然后让当前的Delphi应用程序实现它。然后我们可以进一步移植业务层，最后移植UI。
因此，我正在寻求其他开发人员的一些想法，以了解移动DAL到.NET的一些技术/框架。我的第一个想法是创建一些Web服务。这个想法是将当前的客户端/服务器应用程序移动到.NET。我们可以稍后处理多层设计、Web应用程序等问题。也许正确的答案是从头开始？
非常感谢任何想法或建议。
3
我可以认真地问一下，您为什么要这么做？这是一个很大的转变，需要花费很多时间来实施，您将被困在复制现有功能、引入全新错误以及长期无法推出新功能的困境中。我猜您可能对某些闪亮的.NET技术感兴趣，以便让这种努力变得更有价值。请告诉我们那是什么，这样也许会帮助我们提供更好的建议。请注意，我并不是.NET的反对者；我认为.NET很不错，我相信我将来会使用它，但我不会在可预见的未来迁移我的Delphi应用程序。 - Cosmin Prund
2
@Cosmin：...我认为这就像攀登珠穆朗玛峰一样：人们之所以做到是因为他们能够做到。而且将业务逻辑与UI层分离并不是一个坏主意，从中央服务器向Web和移动客户端提供服务带来了新的用例，并且学习新东西也很有趣（只要有足够的时间和资源）。但我还建议阅读 "Things You Should Never Do, Part I" http://www.joelonsoftware.com/articles/fog0000000069.html。 - mjn
喜欢这篇文章。其中有很多真理... - Adriano Carneiro
3
你为什么不修复 Delphi 应用程序？你真的认为这样会更好吗？像魔法一样吗？不会的。同样的问题还会再次出现。除非你找出导致 Delphi 应用程序失控的原因，否则你会在 C# 中重蹈覆辙，甚至更糟。 - Warren P
不要重写。重写的成本几乎与您在旧产品中投资的成本相同。因此，几年后，您将拥有相同的产品，但存在不同的错误，并且浪费了几年时间。 - Jeroen Wiert Pluimers
5个回答
5

这没有什么神奇的配方。我也是一名 Delphi 开发者，现在正在 .NET 世界工作。

Delphi 是极端的语言。每种语言都可以有良好编写和糟糕编写的软件。但是在 Delphi 中，当应用程序编写得很好时，它就像天堂。当它不好时，就像地狱。你知道我的意思。Delphi 将 RAD 提升到了一个全新的水平，因此您可以快速编写软件。但是它会变得杂乱无章...就像 WinForms 一样，如果您将 SQL 插入命令写在按钮事件中 :)

以下是我的想法：

  • 如果你要使用.NET，请选择C#。不要回头看其他语言。
  • 你应该从数据层开始学习。
  • 如果你想继续使用Delphi UI并将其与.NET DAL配合使用，你可能会惊讶地发现自己不想改用WinForms。有些人可能会对此感到不满，但时间会证明一切......
  • 你可能想将DAL实现为WebServices。这将为你的软件带来许多学习机会，并且还可以重复使用！
  • 从头开始构建你的DAL，你不会后悔。
  • 不要从头开始构建UI。尝试使用现有的UI。UI需要时间。如果你要检查所有现有的屏幕，你将摆脱不良因素，然后连接到新的.NET DAL。但是从头开始构建所有内容是令人不知所措的，并且可能会在长期内压抑团队的士气。
3
你可以使用Delphi Prism。它并不是真正的Delphi，而是为.NET开发的Object Pascal。
然而，从Delphi到Prism的移植将更加容易，因为两者都是Pascal，并且Embarcadero已经付出了努力来使过渡变得容易。
由于它使用的是.NET而不是VCL，所以它不是一个简单的重新编译，但你可以重复使用比你原本想象中更多的东西。
2

这似乎是一个可以使用DataAbstract 的地方，它提供了.Net和Delphi支持（而且正在开发Java版本）。

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

第一步可以将您的应用程序移动到基于Delphi的服务器和客户端，当C/S通信逻辑可行时，可以创建等效的C#服务器，然后切换。

请注意，我并不是说这是一个好主意，只是展示从技术上讲有一种直接的方法。整个抽象层和中间件的想法是更加灵活地处理实际实现。

这是我们与Java程序通信所做的事情：构建Delphi客户端和Delphi服务器模型。然后，负责Java部分的一方未能交付，导致另一方破产。 - Jeroen Wiert Pluimers
2
我��于非常相似的位置。 查看问题 我最初决定使用WCF，但是Delphi WSDL导入程序无法处理它，现在我正在使用ASP.net asmx web服务，并且互操作性得到了极大改善。
我们正在从具有不一致的内联SQL，存储过程和长达900-1200行方法的厚客户端进行逐步迁移，以实现多层解决方案。一旦服务器端功能到位，我们就开始在Delphi客户端中实施更改。这允许现有应用程序继续工作，并且可以分阶段进行测试和部署。
我首先开始实施DAL，并使用Entity framework，我们将所有数据表表示为实体，并使用每个实体的数据传输对象与客户端交换数据。
接下来，业务逻辑将逐个功能区域进行迁移，最后，客户端将仅执行客户端表单应该执行的操作，允许用户与应用程序交互。
我们选择EF的主要原因之一是允许Visual Studio自动生成Delphi类，通过调整t4模板进行更改跟踪（仍在努力）和数据持久化逻辑。
仍然存在一个障碍：从.Net Web服务到客户端的数据绑定在Delphi 2010上仍然不可能。因此，我们将把这个留到最后。
所有这些都将使我们能够更快地针对服务器实施定制的客户请求，而不会破坏客户端设计。
对于那些问为什么并坚持认为这总是一个坏主意的人，请记住，在某些情况下（如我的情况），这些广泛使用的应用程序非常复杂，并且并非所有Delphi开发人员都还在身边来证明有问题的设计和编程决策。当前添加新功能总是一种赌博，当变量具有多重含义时，对于这样大小的应用程序，Delphi 2010 IDE已经不足以创建真正的维护头痛，从Visual Studio转换过来。别误解我，我学习Delphi来进行这种开发，但是以Delphi 5编写这个历史产品的方式是完全不可持续的。
问题不在于为什么，而在于许多情况下：在被迫进行重大重写或放弃产品之前，您可以忽略该问题多长时间？
好的观点。请注意，您需要一些非常优秀的.NET/C#开发人员来实现您的目标。您的Delphi历史绝对不是Delphi独有的：我承接了一套总共约400万行代码的.NET项目，由不同的团队和公司开发，其中一些编写了出色的代码，但大多数只是平庸的。现在我们正在进行一个大的Windows 7 / .NET 4升级，结合逐步稳定和重构阶段。 - Jeroen Wiert Pluimers
1

虽然我认为重写总是一个错误，但你可以像任何技术试验一样开始：制作一个原型。安装Firebird ADO.net连接器，并用C#编写你的数据访问层。

重写现有应用程序总比修复当前应用程序更费力。总是如此。最终，你会失去可移植性，而不是获得它。

如果我要在其他语言中重写Delphi应用程序，即使它不是本地代码，我也会选择Java而不是.net。即便如此，我还是要重申我的第一个观点; 重写是浪费时间和金钱的行为，在我所见过的任何真实商业环境中，它们总是一个错误。然而，人们一次又一次地决定这样做。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接