Использование пользовательских CLR в качестве параметров хранимых процедур SQL Server - PullRequest
Новая
       21

Использование пользовательских CLR в качестве параметров хранимых процедур SQL Server

3 голосов
/ 17 января 2012

Я немного читал об интеграции CLR в SQL Server (я использую 2008 R2, но я считаю, что это мало относится к этому вопросу) и столкнулся с темой UDT CLR. После некоторого прочтения я обнаружил, что большинство людей считают их злыми, советуют не использовать их и даже доходят до того, что предполагают, что они вообще не имеют практического применения. Тем не менее, каждое обсуждение, которое я обнаружил о CLR UDT, вращалось вокруг использования их в качестве типов столбцов для хранения объектов в базе данных, но я не мог найти что-либо об их строгом использовании для упрощения связи между приложением и базой данных.

После работы над многими проектами одной из областей, где мне все еще нужно найти решение, которое мне нравится, является связь между прикладным уровнем и уровнями данных, и поэтому меня всегда интересуют новые подходы. Подход, который я обычно использую, заключается в обработке всего доступа к данным через хранимые процедуры. Однако есть одна вещь, которая меня раздражает, это необходимость поддерживать список свойств объекта и соответствующих столбцов таблицы во многих местах. Например, если у меня есть Product объект данных с 20 свойствами / столбцами, я должен поддерживать этот список свойств в нескольких местах:

  • (1x) таблиц базы данных
  • (3x) создание / извлечение / обновление тела хранимых процедур
  • (3x) создание / получение / обновление списка параметров хранимых процедур
  • (3x) код приложения, вызывающий хранимые процедуры (здесь и заключается объектно-реляционное отображение)
  • (1x) определение класса объектов данных

И вот здесь я вижу потенциальное не злое приложение для UDT CLR: используя UDT CLR, я могу использовать объекты для связи между приложением и базой данных и перемещать объектно-реляционное отображение в хранимые процедуры. Вот пример того, что я имею в виду:

Хранимая процедура обновления продукта: 

CREATE PROCEDURE crudProductUpdate
    @Product udtProduct
AS
    UPDATE Products
    SET Name = @Product.Name,
        Manufacturer = @Product.Manufacturer,
        Price = @Product.Price,
        ...
    WHERE SKU = @Product.SKU

Код приложения для обновления продукта: 

void Update()
{
    using (SqlCommand cmd = new SqlCommand("crudProductUpdate", this.DB)
    {
        cmd.CommandType = CommandType.StoredProcedure;
        cmd.Parameters.AddWithValue("@Product", this);
        cmd.ExecuteNonQuery();
    }
}

Используя этот подход, я смогу сократить места, где мне нужно вести список свойств / столбцов:

  • (1x) таблиц базы данных
  • (3x) создание / извлечение / обновление тела хранимых процедур (здесь и заключается объектно-реляционное отображение)
  • (1x) определение класса объектов данных

На бумаге это кажется почти легким делом, но я уверен, что я недальновиден, и мне не хватает некоторых недостатков этого подхода и потенциально полезного применения ULT CLR. Итак, вопрос в основном таков: какие недостатки и / или проблемы могут возникнуть при таком подходе? Вы бы порекомендовали (против) использовать этот подход?

Ответы [ 2 ]

2 голосов
/ 12 сентября 2012

Я вижу как минимум два косвенных недостатка:

  • Это действительно связывает все приложение с SQL Server.Если однажды в будущем вы захотите изменить уровень постоянства (например, Oracle, PostgreSQL, MySQL и т. Д.), У вас будет много работы.
  • Интеграция двух миров: OOP vs Relational ставит сложные задачи с точки зрения интеграции разработчиков OOP с администраторами баз данных.Чтобы упростить его, разработчики ООП не любят SQL, а администраторы баз данных не любят C #.Таким образом, у вас могут возникнуть проблемы с поиском подходящих людей с соответствующей компетенцией Relational + OOP или даже желанием заняться этим.Я лично думаю, что это неудачно, но это часто реальность в мире предприятия.Если вы поддерживаете приложение только один, это не проблема.

В противном случае, я думаю, что это хороший выбор дизайна.

Обратите внимание, что вы также можете использовать SQL2008 Табличные параметры с пользовательскими типами таблиц для того же самого вида результата без использования средств интеграции CLR / SQL Server.

PS: вы также можете использовать генераторы кода для всего этого,это также сократило бы работу.

1 голос
/ 12 декабря 2013

Ну, если кто-нибудь прочтет это после всего этого времени .....

Если ваша компания использует SQL Server, они обычно остаются с SQL Server, поэтому я думаю, если это ваша среда, и, вероятно, она останется сомом, то это хорошая идея. Я посмотрел на Entity Framework и NHibernate и нашел их все очень замысловатыми - SQL Server и необработанный ADO настолько мощны, всего лишь с несколькими методами, и распределение структуры данных между уровнями приложения и базы данных на самом деле является легкой задачей с пользовательскими переменными таблиц , Упомянутый выше OOP vs DBA является полной версией - если вы разрабатываете приложения, управляемые базами данных, вы должны понимать базы данных, а также архитектуру OO уровня приложений, в противном случае у вас голова в песке.

...