为什么 API 设计如此糟糕？

Question

我们有一个 .NET API 来管理多个应用程序的所有请求。 API 使用

System.Data.SqlClient

与数据库通信，而不是使用实体框架“桥梁”。

它的端点都是通用的——我的意思是最字面意义上的。我们有一个

Get()

、一个

UpdateInsert()

和一个

Delete()

端点。在 HTTP 请求中，我们发送 SQL 查询和参数列表。当编写 API 时，开发人员相对缺乏经验，并且是在 SQL 连接器而不是 EF 上孕育的。所有查询都是参数化的，所以我认为不存在 SQL 注入的风险。

例如：

public static ReturnObject UpdateInsert(string strSQL, Dictionary<string,string> parameters, int appID)
{
    SqlConnection connection = new SqlConnection(ConnectionStringProvider.Retrieve(appID));
                
    connection.Open();

    string returnedValue = "";
                
    try
    {
        using (SqlCommand cmd = new SqlCommand(strSQL, connection))
        {
            try
            {
                foreach (KeyValuePair<string,string> kvp in parameters)
                {
                    cmd.Parameters.AddWithValue(kvp.Key, kvp.Value);
                }

                object result = cmd.ExecuteScalar();
                            
                if (result!=null)
                {
                    // Assign result to returnedValue
                }
            }
            catch (Exception ex)
            {
                // Assign exception to returnedValue
            }
        }
    }
    catch (Exception ex)
    {
        // Assign exception to returnedValue
    }

    // Return returnedValue
}

我的问题是：你能帮我解释一下为什么这是糟糕的 API 设计吗？到目前为止，这是我戴上干净的架构帽子所能想到的：

• 违反单一责任原则（一个API p/responsibility）
• 原始 SQL 公开有关数据库实现的信息（HTTP 请求中包含原始 SQL 也是安全问题吗？）
• 使用 SqlClient 将数据库实现设置为石头
• 不鼓励在使用它的应用程序中进行良好的架构设计

我确信我还缺少其他东西。我以前从未见过这样的 API，我想知道为什么。