将应用程序从 Delphi 迁移到 Silverlight C#
我有一个使用 Delphi 5 和 Delphi 开发的旧桌面会计应用程序。 Paradox，我打算将其迁移到带有 SQL Server 的基于 Web 的 Silverlight（为了用户体验）应用程序。
有人可以建议一种快速实施此方法的方法吗？
我知道这是一个非常开放式的问题，我并不是在寻找具体的答案。相反，来自 SO 用户的意见/经验。
我主要关心的是迁移方法、可能的架构和设计模式（对于 SL，我知道 MVVM）实现。
I have a legacy desktop accounting application developed using Delphi 5 & Paradox, which I intend to migrate to a web based Silverlight (for the sake of UX) application with SQL Server.
Can anybody suggest a way to implement this quickly?
I know this is a very open-ended question and I am not looking for concrete answers. Instead opinion/experiences from SO users.
My main concern is about migration approach, possible architecture and design patterns (for SL I know of MVVM) implementation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
迅速地？这是每个经理都想要的，但我对此表示怀疑。
您拥有根本不同的 UI 模型和不同的编程语言。
除非这些应用程序很小，否则不太可能在短时间内手动转换它们（甚至是你自己，因为OP似乎暗示“我打算”）。
Gartner Group 分析了手动迁移，并建议如果一切都“相似”，则实际转换率约为 150 行/天，这是可能的，因为您或多或少是直接从正在运行的、已调试的应用程序进行转换。 （SLOC 中的应用程序到底有多大？）因此，如果您有 75,000 行代码，那么您至少需要 500 个工作日。您可能会认为 Delphi 作为编程语言和 C# 是相似的。您无法合理地为 Delphi UI 和 Silverlight 做出这种情况，因此这个估计是一个下限。
有人说，“把它扔掉，然后从头开始重新编码”。除非您的生产力每天超过 150 行调试代码[经典软件工程文本会告诉您它比这小得多]，否则这将花费您更长的时间。通常它会失败，因为您最终忘记了当前程序中存在哪些功能，并在开发后期重新发现它们，或者在尝试重新部署后更糟。通常发生的情况是，在构建新应用程序的同时，旧应用程序不断发展（请记住，距离新应用程序的最低要求还差 500 个工作日！），而新应用程序必须赶上这些变化。如果应用程序具有严重的规模（例如，一百万行），这通常会阻止新应用程序的可用。另一种思考方式是，“构建原始应用程序需要多长时间？”以及“为什么构建替代应用程序要容易得多？”。 YMMV，如果你能创造奇迹。
我非常有偏见的观点（我构建语言翻译工具）是最实用的方法之一是自动翻译。这也是有代价的。无论别人告诉你什么，它们都不是现成的产品。您已经设置了翻译器，这也需要大量的能量，但是该能量与所使用的语言和（UI）库功能的大小成正比，而不是比应用程序的大小更有效，因此当程序变大时它会更有效。仅针对语言翻译部分进行编码和测试仍然需要数百个工作日。不同之处在于，一旦设置完毕，您就可以将其应用于任何大小、任何状态的现有应用程序。还有比这更复杂的情况，但这种方法克服了手动转换的“无法赶上”的问题，以及“无法获得足够的编码人员来手动翻译它”。
有关更多详细信息，请参阅我的有关如何在语言之间进行翻译的答案。
如果您的应用程序相对较小，恕我直言，没有好的答案。手工翻译或重新编码可能是您唯一的（丑陋的）选择。
Quickly? That's what every manager wants, but I doubt it.
You have fundamentally different models of UIs, and different programming languages.
Unless these applications are small, it is unlikely that will be able to convert them by hand in any short period of time (or even by yourself as it appears the OP implies "I intend").
Gartner Group has analyzed manual migrations, and suggests if everything is "similar" the actual conversion rate is ~~ 150 lines/day, which is possible because you are translating more or less directly from a working, debugged application. (Just how big is the application in SLOC?) So, if you have 75,000 lines of code, you're looking at 500 man-days minimum. You might make the case that Delphi as programming langauges and C# are similar. You cannot reasonably make that case for the Delphi UI and Silverlight, so this estimate is a lower bound.
There are those that say, "just throw it away and recode it from scratch". Unless your productivity exceeds 150 debugged lines of code per day [classic software engineering texts will tell you it is much smaller than this] this will take you even longer. Usually it fails because you end up forgetting what features exist in the current program, and rediscover them late in development or worse after an attempted reployment. Usually what happens is the old application continues to evolve while the new one is being built (remember, you're 500 man-days away from the new one minimum!) and the new one has to play catchup with these changes. If the application has any serious scale (e.g., a million lines) this often prevents the new one from ever being servicable. Another way to think about this, "how long did it take to build the original application?", and "why should building a replacement be enormously easier?". YMMV, if you can work miracles.
My very biased opinion (I build langauge translation tools) is that one of the most practical ways to do this is automated translation. This has its costs, too; they aren't off-the-shelf items no matter what somebody tells you. You have set up the translator, and that also takes a lot of energy, but that energy is proportional to the size of the language and (UI) library features used, rather than the application size, so it is far more effective as the program gets large. This is still on the order of hundreds of man-days to code and test for just for the langauge translation part. The difference is that once set up, you can apply it to the existing application of whatever size in whatever state it happens to be in. There's more complications than this, but this approach overcomes the "can't catch up" problem of manual conversions, and the "can't get enough coders to manually translate it".
For more details, see my answer on how to translate between languages.
If your application is relatively small, there are IMHO no good answers. Hand translation or recoding are likely your only (ugly) choices.
我的建议是，当需要额外功能时，使用 Silverlight 创建“增值”附加功能并更新您的应用程序，直到您获得类似于完整产品的东西。
对我来说，开发 Silverlight 似乎需要很长时间，而且业务应用程序的用户体验并没有比 ASP.NET Ajax 得到大幅改进（如果 Ajax 正确完成的话）。我想，如果您今天坐下来，在 Silverlight 中完全重写一个相当大的应用程序，那么在您的开发完成之前，Silverlight 就会结束生命（当然，除非您投入了一个庞大的团队）
My suggestion would be to create "value add" extras and updates to your application using Silverlight as and when the need for extra functionality comes up until you've got something resembling a full product.
To me developing Silverlight seems to take a very long time and the UX for a business application isn't massively improved over say ASP.NET Ajax (if the Ajax is done properly). I imagine if you were to sit down today and completely re-write a decent size application in Silverlight then Silverlight would be end of life before your development is completed (unless you threw a massive team at it of course)
如果您的业务逻辑与 UI 很好地分离，您可以从将代码“移植”到 Delphi Prism 而不是 C# 开始。这提供了更短的迁移路径。如果您的业务逻辑与 UI 紧密耦合（就像 10-15 年前经常发生的那样），那么从头开始重写所有内容可能是一个更好的主意。
一旦你启动并运行了 Pascal 中的所有代码，在反编译器的帮助下用 C# 重写它（如果你最后需要它）几乎是微不足道的。
If your business logic is well separated from the UI, you can start with "porting" your code to Delphi Prism rather than C#. This offers shorter migration path. If your business logic is tightly coupled with UI (as it happened frequently 10-15 years ago), then rewriting everything from scratch could be a better idea.
And once you have all the code in Pascal up and running, rewriting it in C# (if you need it at the end) is almost trivial with help of decompiler.