Шаблоны доступа к данным в SQLCLR

Question

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

Обычно я общаюсь между .net и SQL, используя хранимые процедуры, потому что мне всегда нужен API для моей базы данных. Однако в этом случае код .net является частью API, поэтому SP кажутся плохими.

Linq2SQL не существует на сервере SQL (хотя его можно установить, делая то, что администраторам не понравится), поэтому это не вариант.

То, что у меня сейчас есть, это мой код, загроможденный стандартным кодом ADO.NET, таким как

using (SqlCommand cmd = c.CreateCommand()) {
    cmd.CommandText = "SELECT ... FROM ...";
    using (SqlDataReader rdr = cmd.ExecuteReader()) {
        DoSomething(rdr);
    }
}

и, хотя, это работает, это просто очень похоже на неправильный способ сделать это.

Как другие люди это делают?

Answer 1

Я использую XSLT для генерации кода C # для DAL. Обычно я загружаю XML из самого определения базы данных (например, некоторая форма SELECT name, type, length, ... FROM sys.columns JOIN sys.tables JOIN sys.types FOR XML PATH), и я разработал со временем собственное XSLT-преобразование для генерации кода. Я добавил их как часть самого процесса сборки Visual studio, аналогично этому блогу: http://rusanu.com/2009/04/11/using-xslt-to-generate-performance-counters-code/ (блог посвящен счетчикам производительности generaiton, но он также применим и к коду DAL). Я также создаю типы для наборов результатов, используя код XSLT gen.

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

Этот подход, в первую очередь, очень гибкий , позволяющий мне быстро вносить глобальные изменения, влияющие на каждую точку входа DAL, в то время как я сохраняю абсолютный контроль над базой кода (без внешних зависимостей, без внешних ошибок) ). Он очень легкий по сравнению с наборами данных ADO.

Я бы обменял этот подход только на LINQ из-за добавленной стоимости передачи объектов IQueryable. Но в SQLCLR, как вы знаете, это еще не жизнеспособный вариант.

Answer 2

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