DRY CLR табличные функции

Я использую табличную функцию CLR для SELECT и возвращает результаты сложного поиска в базе данных, который использует много переменных.

Документация показывает, что вы создаете такую ​​функцию способом, подобным этому:

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;
    }
}

Проблема в том, что это довольно повторяющееся. Сначала вы определяете таблицу в блоке SqlFunction. Затем, когда вы добавляете или удаляете столбцы в результатах, которые вы возвращаете, вы должны убедиться, что вы обновили его и

  • определение в ResultRow
  • аргументы конструктора в ResultRow
  • назначение в ResultRow
  • типы, извлеченные из читателя в Test()
  • выходные аргументы в Test_FillRow()
  • назначения в Test_FillRow()
  • и сам SQL-запрос, который является единственной частью, с которой вы действительно пытаетесь начать.

Я работаю над такой функцией, которая принимает более двадцати аргументов, возвращает еще больше строк и содержит эти восемь возможных мест для ошибок. Восемь Все ошибки тривиальны и легко исправимы, но их очень легко сделать, потому что в коде так много мест, которые я должен вручную синхронизировать.

Это нарушение СУХОГО, но я не знаю, как устранить повторение. Есть ли более краткий способ написания табличных функций CLR?

Источник

2 ответа

Решение

Если вы замените ResultRow на object[], вы можете использовать reader.GetValues ​​(object[]) и избавиться от необходимости знать, что находится в строках, до FillRow(), а затем FillRow отвечает за знание того, в каком порядке были поля в оригинальный запрос.

Это действительно компромисс, вы можете полностью отказаться от строгой типизации, взамен того, что вам не придется выполнять строгую типизацию до конца, но трудно иметь обе стороны:-)

Источник

Если вы превратите свои наборы параметров в классы, вы можете использовать универсальный метод, ограниченный их базовым классом, для реализации доступа к данным. Я обнаружил, что обычно класс, используемый для передачи параметров в группы, как обычно, будет полезен в других местах, а также в рефакторинге.

Обычно никогда не бывает хорошей идеей передавать двадцать параметров в функцию.

Вот хорошее резюме, с которым я в целом согласен в отношении аргументов функции: http://benbiddington.wordpress.com/2009/06/22/book-review-of-clean-code/

В частности:

Если функция ожидает более двух или трех аргументов, вероятно, что по крайней мере некоторые из них должны быть заключены в свой собственный класс.

В этом случае выгода от этого, вероятно, может заключаться в извлечении некоторых общих методов, которые помогут вам более плотно придерживаться DRY.

Источник
Другие вопросы по тегам