DRY CLR table-valued functions

2019-04-29 23:57发布

问题:

I'm using a CLR table-valued function to SELECT and return the results of a complex database search which uses many variables.

The documentation shows that you build such a function in a fashion similar to this:

public partial class UserDefinedFunctions
{
    private class ResultRow
    // This class holds a row which we want to return.
    {
        public SqlInt32 CustId;
        public SqlString Name;

        public ResultRow(SqlInt32 custId_, SqlString name_)
        {
            CustId = custId_;
            Name = name_;
        }
    }

    [SqlFunction(
        DataAccess = DataAccessKind.Read,
        FillRowMethodName = "Test_FillRow",
        TableDefinition = "CustId int" +
                          "Name nvarchar(50)")]
    public static IEnumerable Test()
    // This function contains the actual logic.
    {
        ArrayList results = new ArrayList();

        using (SqlConnection connection = new SqlConnection("context connection=true"))
        {
            connection.Open();

            using (SqlCommand select = new SqlCommand(
                "SELECT TOP 100 custid, name FROM Customers",
                connection))
            {
                using (SqlDataReader reader = select.ExecuteReader())
                {
                    while (reader.Read())
                    {
                        results.Add(new ResultRow(
                            reader.GetSqlInt32(0),  // CustId
                            reader.GetSqlString(1)  // Name
                        ));
                    }
                }
            }
        }
        return results;
    }

    public static void Test_FillRow(
        object resultsObj,
        out SqlInt32 custid,
        out SqlString name)
    // This function takes a row and tells SQL Server what variables we want to 
    // return from it and what types it contains.
    {
        ResultRow selectResults = (ResultRow)resultsObj;

        custid = selectResults.CustId;
        name = selectResults.Name;
    }
}

The problem is, it's rather repetitive. First you define the table in the SqlFunction block. Then as you add or remove columns in the results you're returning, you have to make sure that you update it and

  • the definition in ResultRow
  • the arguments to the constructor in ResultRow
  • the assignment in ResultRow
  • the types grabbed from the reader in Test()
  • the out arguments in Test_FillRow()
  • the assignments in Test_FillRow()
  • and the SQL query itself, which is the only part you're really trying to think about to start with.

I'm working on such a function which takes over twenty arguments, returns even more rows, and contains these eight possible places to make mistakes. Eight. All the mistakes are trivial and easily fixed, but it's very easy to make them because there's so many places in the code which I have to manually keep in sync.

This is a violation of DRY, but I don't know how to eliminate the repetition. Is there a more concise way to write CLR table-valued functions?

回答1:

If you replace your ResultRow with object[], you can use reader.GetValues(object[]) and eliminate having to know what's in the rows until FillRow(), and then FillRow is responsible for knowing what order the fields were in in the original query.

It's really a tradeoff, you can give up having strong typing all the way through, in exchange for not having to do strong typing all the way through, but it's hard to have it both ways :-)



回答2:

If you made your parameter sets into classes, you could use a generic method constrained on their base class to implement the data access. I've found generally a class used to pass parameters in groups like will usually find usefulness elsewhere as well as you refactor.

It's generally never a good idea to pass twenty parameters to a function.

Here's a good summary that I generally agree with on function arguments: http://benbiddington.wordpress.com/2009/06/22/book-review-of-clean-code/

Specifically:

If a function expects more than two or three arguments, it’s likely that at least some of those should be wrapped in their own class.

In this case, the benefit of this may likely be the extraction of some generic methods that will help you adhere more tightly to DRY.