VB.NET GUI - TSQL 动态 SQL 噩梦设计

Question

这更像是一个设计问题，而不是实现问题。我们的数据库有一个 VB.NET 前端。当前的设计是使用元数据表来执行“前端无 SQL”策略。我认为我们所做的事情比硬编码更糟糕，因为我们现在有一些 STORED PROC 意大利面条代码。例如，我们有很多动态 SQL 用于构建表的完全限定名称，然后将其发送回另一个处理纯文本文件实际加载的存储过程。

    ID DATA_TABLE_NAME DATA_TABLE_SCHEMA PTR_TABLE_NAME PTR_TABLE_SCHEMA
    1  datatable            DBO            datatable_ptr       DBO

所以我们有一个类将获取数据表名称和表指针，并将其混合到 VB.NET 前端中的一个类中，该类发送一个全名，如映射到 database.dbo 的 database.dbo.datatable。 datable_ptr 并使用全局临时表来加载平面文本文件。好吧，有人在这个讨厌的元数据小表中添加了一行，它破坏了 VB.NET 前端!必须有更好的方法来执行此操作，但我没有足够的经验来提出更好的通用解决方案。

程序员究竟如何强调代码重用和使用 T-SQL 和 VB.NET 的泛型编程，同时保持代码的可读性和可维护性？有没有人可以推荐一些关于设计模式的书籍或一本可以为我指出更可行的解决方案的 cooking 书？

Answer 1

在开始我提出的解决方案之前，我认为我需要先披露一些事情:

1) 我只有 2 年多一点的专业编程经验。
2)我是短视的，因为我只对我每天使用的数据库有经验。
3) 我只在一家(和目前的)vb.Net/TSQL 公司工作过。

也就是说，如果出现以下情况，我会这样做:

1) 您的经理很可能希望看到某种可量化的进展。
2) 您正在寻找一种实用的方法来解决这个问题(这个提议的解决方案提供了什么)，以促进上述可量化的进展。
3)你需要保持“前端无SQL”的理念。
4) 您需要可扩展的东西，这样当 35 个以上的应用变成 75 个以上的应用时，您仍然可以。

解决方法:
1. 创建一个新的数据库，就好像前端允许 SQL(即“你一直想要的”)。
2. 创建一个 Web 服务，作为前端(不能有 SQL)和“你一直想要的”数据库之间的中间人。这将解决问题。数据库结构不需要混淆，因为它会从最终用户那里删除两次。

方法:
1) 最初，动态 SQL 可以“按原样”移动到 Web 服务。当意大利面条的一部分被翻译时，它可以留在那里。我们可以称其为“主函数”，或“旧的做事方式”。
2) 为每个申请指定一名组长(或每 5 份申请指定一名组长，等等)。他们的责任是在创建他们的 Web 服务部分时充当联络人。您将需要知道他们需要什么表，并且他们在创建 Web 服务时需要知道您想要的格式。
3) 一次接受一个申请:
A) 设置他们需要的数据库表
B) 创建 Web 服务以将这些表与前端连接
C) 创建从前端调用 Web 服务的函数。首先尝试与新数据库表接口(interface)的新函数，然后像现在一样尝试 Master 函数与数据库接口(interface)。

随着应用程序被切换到使用它们的“个性化”网络服务功能，Master 功能应该做的越来越少(即你慢慢停止使用意大利面条存储过程)。此外，作为 Web 服务的创建(到此结束时，贡献者可能与应用程序)是分散的，工作可能会进行得相当快，并且由于主函数将是第一个启动和运行的东西，你的整体运作应该仍能照常进行。