3

这更像是一个设计而不是实现问题。我们的数据库有一个 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.datatable 映射到 database.dbo.datable_ptr 并使用全局临时表加载平面文本文件。好吧，有人在这个讨厌的元数据小表中添加了一行，它破坏了 VB.NET 前端！必须有更好的方法来做到这一点，但我没有足够的经验来提出更好的通用解决方案。

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

4

1 回答 1

1

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

1）我只有2年多的专业编程经验。
2）我目光短浅，因为我只对我每天使用的数据库有经验。
3) 我只与 ONE（和当前）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 服务。首先尝试与新数据库表接口的新函数，然后尝试像现在一样与数据库接口的 Master 函数。

随着应用程序切换到使用它们的“个性化”Web 服务功能，主功能应该做的越来越少（即您慢慢停止使用意大利面条式存储过程）。此外，由于 Web 服务的创建（到此结束时可能有与应用程序一样多的贡献者）是分散的，因此工作可能会很快进行，并且由于主功能将是第一个启动和运行时，您的整个操作应该仍然可以照常进行。

于 2013-06-19T16:56:27.250 回答