将旧桌面应用程序移动到健壮的平台上

Question

几年前，我用Delphi 7编写了一个桌面应用程序，一个小型的会计系统，它是一家中型公司的用户。密码是我的。我移植了我几年前构建的另一个会计系统(Delphi/IB)，使用SQL Server并在空闲时间添加了新的业务规则，然后我将应用程序提供给了公司。(没有合同，没有许可证，只是代码是我的，没有人争论)。

它目前通过直接连接到数据库来工作。应用程序中的每个用户都是数据库中的用户。我为用户能够看到的每个表单定义了角色，并且它们与SQL Server中的DB角色相匹配，因此，即使是错误地，您也不会看到不应该是的数据。我还设法破坏了密码，这样用户(普通用户，而不是黑客)即使知道服务器的ip/端口，也永远无法直接连接到DB。多年来，它一直以这种方式运作。

一位新的IT管理人员，很多新人，对我的申请不以为然。请注意，该公司还使用SAP的许多分支机构和我的会计系统服务器，目的是一种合并系统。他们不喜欢客户机/服务器体系结构，并且指出了安全风险和其他不安全的因素。我同意我的C/S架构，我连接到数据库的方式感觉不太可靠。

我想我需要中间的“东西”。但是研究三层应用程序时，我淹没在同一应用程序中的一堆关于3层的文章中，我的意思是，在同一个应用程序中数据的分离，而我想我需要的是桌面应用程序和数据库之间的第二层软件。我想我也需要一个应用服务器，可能是吗？

我还能流利地使用C#，最近我用C#编写了更多的桌面应用程序，然后用Delphi编写了更多的桌面应用程序，因此如果需要的话，我可以将Delphi代码迁移到C#。因为代码是我的，这是一种投资，我将来可能会投资。这就是为什么，除了IT的要求之外，我还想让它更加健壮。

我在找一篇文章，让我开始写这样的软件。WCF，Midas，ORM？

不想装腔作势，我期待着创建一个健壮的平台，就像SAP-ERP中使用的平台一样。因此，我可以扩大应用程序添加新的模块，如控制，工资，账单等，并把它变成一个小的ERP。

Answer 1

抱歉，但这太疯狂了。用不同的语言重写一个工作的应用程序，因为有人不喜欢数据访问管道的样式？！这是不必要的花费、努力、破坏和风险。ROI在哪里？时间对价值是多少？如果问题描述了完整的推理，那么标准的go/no-go业务度量标准就不可能支持翻版和替换。

这不是因为我不同意。直接到数据库的连接有一些真正的缺点，例如可伸缩性有限，并且可能违反最小特权安全方法。它们将数据解释锁定在客户端应用程序中，使得多平台应用程序、长版本尾以及数据分析等组合任务更具挑战性。德尔菲7的牙齿有点长了。等。等。

如果您是一家商业软件公司，需要大幅度增加并发用户的数量，需要与不那么可靠的用户一起操作，或者在不太安全的网络上操作，或者有特定的特性需要直接到数据库的连接受到阻碍或阻止，那么我将首先同意“更新您的架构”或“更新您的工具”。但至少从你的问题上看，情况似乎并非如此。你是一家中等规模的公司；软件似乎在做它的工作；而且没有明确的动机来进行一次干净的重建或主要的轮式耕作。这使得这是一个重大的更新，以符合某人的架构偏好。这违反了非夜孕(“第一，不伤害”)，为可疑的利益。

更糟糕的是，您可能没有好的测试套件来确认一个新的干净的纸构建是否正确。(不要对此感到太难过--大多数商店都不适合自己的内部应用程序。)如果是会计软件，错误的数据可能会对商业造成极大的负面影响。所有这些都高喊着“这将是糟糕的结局！”--或者至少，“你最终会不高兴，因为你决定重建一些已经因为不稳定的原因而起作用的东西，而不是去做一些能够真正帮助公司的事情。”我见过太多干净的项目就这样结束了。

主要的罗托--耕耘或重新开始--可以奏效--但你必须有足够的支持、管理和用户来接受它，这将需要一段时间，并在这一过程中引入干扰，最重要的是，这是走这条道路的坚实理由。

相反，我建议您检查您可能从德尔菲7中获得什么增量更新路径？，并制定更多的增量计划和更多基于利益的动机来进行实质性的更改。

Answer 2

不清楚您是说您的CIO设计的问题是持久的DB连接，还是使用映射到DB用户的应用程序用户。这两者都不一定是糟糕的架构，这取决于需求。有许多应用程序会做同样的事情，甚至在Oracle Enterprise上运行高端应用程序。

而且，即使您消除了持久的直接连接，一个在本地运行应用程序的称职的管理员(更不用说黑客)，不管有没有访问DB服务器的权限，只要他们工作得够努力，就能够直接连接到数据库。为什么这是个问题？当然，您不希望它公开，但是内部应用程序可以使用防火墙规则来管理，或者在同一台服务器上共同驻留应用程序+ db。传统上，如果在应用程序中嵌入数据库引擎，则不会更改端口。安全不能以默默无闻为基础。要么确保应用程序是共同驻留的，以便除了本地主机之外没有DB网络连接，要么确保它使用加密会话，从而消除了网络窥探的问题，但留下了本地黑客的可能性。除此之外，还有什么问题呢？

您不能将数据库实例专门用于应用程序吗？也许他希望您的应用程序与其他应用程序在Server实例上共存。如果是这样的话，我可以理解这个要求，这是一件好事。您选择将用户映射到真正的DB用户并不是一个很好的选择，但这并不是世界末日，这更像是一种老式的设计，但限制了您的选择(需要专用数据库)。既然它起作用了，你就得权衡一下成本。也许你的首席信息官已经有了。

接下来，用于本地安装的桌面应用程序的本地服务器(本地LAN)是最常见的模型。否则，要么移动到完整的SaaS web模型，要么使用断开连接的同步。它不是OLTP web服务器，所以我不理解持久化会话的问题。如果他被困在这一点上，重新架构it...here仍然有一些好处，这是一些选项。

您可以通过创建服务“代理”(WCF服务提供数据调用)将连接的SQL设计移植到断开连接的SOA设计。您需要将所有查询映射到服务调用，在服务层中实现它们，然后将该服务层部署为数据库的前端。您仍然可以任意使用胖客户端数据网格，但是通过WCF或data从app到broker、broker到DB的数据流，如果您需要花哨，可以实现IQueryable和您自己的自定义数据源，以允许任意查询条件。我并不是说过渡是无痛的和廉价的，但它是有效的。优点是您可以将数据服务器移动到Internet上的任何地方(云)，并且您的fat应用程序仍然可以在HTTP/HTTPS上工作。C# / .NET是这方面的完美选择。它的服务互操作性非常丰富。

如果您的数据库在LAN/WAN上不是本地的，而且性能/延迟是一个问题，那么我还成功地使用了其他选项，例如实现本地SQLAnywhere数据库、复制主DB的模式，以及使用Mobilink与统一数据库进行同步。有许多具有嵌入式SQLAnywhere或Ultalite DB或SQLLite DB的商业产品使用这种体系结构。(不想泄露我的行当，但是.)