使用CLR UDT作为SQL Server存储过程参数

我一直在阅读关于SQL Server中的CLR集成（我正在使用2008 R2，但我相信这与这个问题几乎没有关系），并且碰到了CLR UDT的主题。经过一番阅读后，我发现大多数人认为他们是邪恶的，反对使用他们的建议，甚至表示他们没有任何实际的应用。然而，我发现关于CLR UDT的每次讨论围绕使用它们作为列类型将对象存储在数据库中，但我无法找到任何有关严格使用它们以缓解应用程序与数据库通信的任何内容。使用CLR UDT作为SQL Server存储过程参数

在完成了很多项目之后，我仍然需要找到一个解决方案，其中一个领域是应用程序层和数据层之间的通信，因此我总是对新方法感兴趣。我通常采用的方法是通过存储过程处理所有数据访问。然而，有一件事情让我很烦恼，它不得不在很多地方维护一个对象的属性列表和相应的表列。举例来说，如果我有20个物业/列的Product数据对象，我要保持在几个地方属性列表：

（1X）数据库表
（3次）创建/检索存储/更新程序的身体
（3×）创建/检索/更新存储过程参数列表
（3×）的应用程序代码调用存储过程（本文位于对象关系映射）
（1×）数据对象的类定义

这里是我看到CLR UDT的一个潜在的非邪恶应用程序：使用CLR UDT我可以使用对象在应用程序和数据库之间进行通信，并将对象关系映射移动到存储过程。下面是我的意思的例子：

产品更新存储过程：

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）数据库表
（3×）创建/检索/更新存储过程的身体（在此位于对象关系映射）
（1×）的数据对象的类定义

在纸面上这似乎像一个没有脑子，但我相信我是短视的，我错过了这种方法的一些缺点，以及CLR UDT的潜在有用应用。所以，这个问题基本上是：这种方法会产生什么缺点和/或问题？你会推荐（反对）使用这种方法吗？

来源

2012-01-17 MarioVW

任何人有任何关于这个问题的想法？ – MarioVW 2012-09-11 07:51:02

“我发现大多数人发现它们是邪恶的” - 我猜那些人不会使用“geography”或“geometry”类型，因为那些是CLR类型。 – 2012-09-11 07:57:59

我可以看到至少两个间接缺点：

这真的绑整个应用程序到SQL Server。如果将来有一天，你想改变持久层（比如说Oracle，PostgreSQL，MySQL等），你将需要做很多工作。
两个世界的整合：OOP vs Relational在OOP开发人员与DBA的整合方面提出了难题。为了简化它，OOP开发人员不喜欢SQL，而DBA不喜欢C＃。因此，您可能无法找到具备正确的Relational + OOP能力的合适人选，甚至是解决问题的意愿。我个人认为这很不幸，但这往往是企业界的现实。如果你是唯一维护应用程序的人，那不是问题。

否则，我认为这是一个很好的设计选择。

请注意，您也可以使用SQL 2008 Table-Valued parameters with user-defined table types作为使用CLR/SQL Server集成工具的同类结果。 PS：你也可以为所有这些使用代码生成器，这将减少工作。

来源

2012-09-12 07:59:26

在一年后看到这一点，对于使用代码生成器（NHibernate，LINQ to SQL等）的建议+1。 – MarioVW 2013-08-22 20:39:34

那么，如果任何人都在此时间后读取该.....

如果贵公司使用SQL Server时，他们通常保持与SQL Server，所以我想如果这是你的环境，并可能保持索姆那么这是一个好主意。我查看了Entity Framework和NHibernate，发现它们都非常复杂 - SQL Server和原始ADO功能非常强大，只需几个方法，并且在应用程序层和数据库层之间弹跳数据结构，实际上是用户定义的表变量。上面提到的OOP vs DBA是完整的 - 如果您正在开发数据库驱动的应用程序，您应该了解数据库以及应用程序层的OO体系结构，否则您的头就在沙滩上。

来源

2013-12-11 23:13:02

使用CLR UDT作为SQL Server存储过程参数

回答

相关问题