1

我最近遇到了一个程序，它是使用表中的 sql 语句开发的，每个语句都有一个代码。而不是在程序本身中有特定的 sql 语句。

所以，不要有这样的代码：

string query = "SELECT id, name from [Users]";
cmd.ExecuteQuery(query);

他们使用这样的代码：（简化）

string firstQuery = "SELECT queryText from [Queries] where queryCode = 'SELECT_ALL_USERS'";
string userQuery = cmd.ExecuteQuery(firstQuery);//pretend this directly returns the result of the first query

cmd.ExecuteQuery(userQuery);

据我所知，这背后的逻辑是它使程序更易于维护，因为开发人员可以自由更改“用户 sql”，而无需实际更改程序。

然而，这让我觉得可能有点适得其反。这种代码会被认为是一个好主意吗？

编辑：我不是在寻找像“使用 ORM”这样的建议。假设 sql 查询是唯一的选择。

4

2 回答 2

7

在我看来，这种做法是荒谬的。将尽可能多的 SQL 与中间层分离是有价值的（可维护性、模块化），但为了实现这一目标，我建议使用存储过程。

于 2013-05-07T14:34:32.793 回答
3

不，我真的不认为进一步进行设计是个好主意。

由于测试或学习活动是一个不同的部分，但绝对不建议继续进行此类实现。

优点：

1. 我们得到了完全的模块化。Real Business Schema 可以随时更改，我们无需修改 Running 应用程序即可从不同的模式中获取结果（考虑到结果格式不要更改）。

缺点。 1. 有了这个实现，我们每次要执行 1. 时都会向数据库触发 2 个 SQL。包括 DB 调用在内的 I/O 调用总是会遇到性能问题，通过这个实现，我们将性能翻倍，这绝对是不可取的。

于 2013-05-07T14:37:21.933 回答