使用CLR的UDT的SQL Server存储过程的参数 [英] Using CLR UDTs as SQL Server stored procedure parameters
问题描述
我一直在做一些阅读有关CLR集成在SQL Server中（我使用的是2008 R2，但我相信这是无关紧要的问题），并撞到了CLR的UDT的主题。一些阅读后，我发现，大多数人觉得他们是邪恶的，建议不要使用它们，甚至远去，因为这表明他们没有实际应用的任何责任。但是，每次讨论中，我发现关于CLR的UDT使用围绕在他们周围列类型来存储对象在数据库中，但我无法找到使用它们严格用于缓解应用程序与数据库的通信东西。
I've been doing some reading about CLR integration in SQL Server (I'm using 2008 R2, but I believe this is of little relevance to the question), and bumped into the subject of CLR UDTs. After some reading, I found that most people find them to be evil, advice against using them, and even go as far as suggesting they have no practical application whatsoever. However, every discussion I found about CLR UDTs revolved around using them as column types to store objects in a database, but I couldn't find anything about using them strictly for easing application-database communication.
在许多项目中工作过之后，的地方我还是要找到一个解决方案，吸引我的是应用程序和数据层之间的通信，因而我一直感兴趣的新方法。我通常采取的办法是处理通过存储过程中的所有数据访问。然而，有一件事让我很烦，这是必须维护一个对象的属性和相应的表列在许多地方的名单。举例来说，如果我有一个产品 20的属性/列中的数据对象，我要保持这个属性列表中的几个地方：
After having worked on many projects, one of the areas where I still have to find a solution that appeals to me is the communication between the application and data layers, and thus I'm always interested in new approaches. The approach that I usually take is handling all data access through stored procedures. However, there's one thing that annoys me, which is having to maintain the list of an object's properties and the corresponding table columns in many places. For example, if I have an Product data object with 20 properties/columns, I have to maintain this property list in several places:
- （1X）数据库中的表
- （3次）创建/检索/更新存储过程的身体
- （3次）创建/检索/更新存储过程的参数列表
- （3倍）的应用code调用存储过程（就在于此对象 - 关系映射）
- （1X）的数据对象类定义
和这里的地方我看到了潜在的非恶申请CLR的UDT：使用CLR的UDT我可以使用对象的应用程序和数据库之间的通信，以及移动的对象 - 关系映射到存储过程。下面是我的意思的例子：
And here's where I see a potential non-evil application for CLR UDTs: using CLR UDTs I could use objects to communicate between the application and the database, and move the object-relational mapping to the stored procedures. Here's an example of what I mean:
产品更新存储过程：
CREATE PROCEDURE crudProductUpdate
@Product udtProduct
AS
UPDATE Products
SET Name = @Product.Name,
Manufacturer = @Product.Manufacturer,
Price = @Product.Price,
...
WHERE SKU = @Product.SKU
产品更新应用程序code：
Product update application code:
void Update()
{
using (SqlCommand cmd = new SqlCommand("crudProductUpdate", this.DB)
{
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("@Product", this);
cmd.ExecuteNonQuery();
}
}
使用这种方法，我就能够减少我需要保持财产/列列表中的地方：
Using this approach, I would be able to cut down the places where I need to maintain the property/column list:
- （1X）数据库中的表
- （3次）创建/检索/更新存储过程的身体（就在于此对象 - 关系映射）
- （1X）的数据对象类定义
在纸本似乎像一个没有脑子，但我敢肯定我是短视的，我错过了一些缺点，这种方法，和CLR的UDT可能有用的应用程序。因此，问题主要是：可能产生这种做法有什么缺点和/或问题？你会推荐（反对）使用这种方法？
On paper this almost seems like a no-brainer, but I'm sure I'm being short-sighted and I'm missing some drawbacks to this approach, and potentially useful application of CLR UDTs. So, the question basically is: What drawbacks and/or problems could arise from this approach? Would you recommend (against) using this approach?
推荐答案
我可以看到至少两个间接缺点：
I can see at least two indirect drawbacks:
- 这真的纽带整个应用程序到SQL Server。如果有一天，在未来，你要更改的持久层（说甲骨文和PostgreSQL，MySQL的，等等），你将有很多工作要做。
- 在两个世界的融合：面向对象VS关系带来了集成的面向对象开发VS数据库管理员而言艰巨的挑战。过于简单化的，面向对象的开发者不喜欢SQL和数据库管理员不喜欢C＃。所以，你可能很难找到合适的人与合适的关系+ OOP能力，甚至会解决它。我个人认为这是不幸的，但是这往往是在企业的现实世界。如果你是唯一一个保持应用程序，这不是一个问题。
另外，我觉得这是一个很好的设计选择。
Otherwise, I think it's a good design choice.
请注意，您还可以使用 SQL Server 2008表值参数与用户定义的表类型，在同一种结果的W / O使用CLR / SQL Server集成服务。
Note you can also use SQL 2008 Table-Valued parameters with user-defined table types for the same kind of result w/o using the CLR/SQL Server integration facilities.
PS：你也可以使用code发电机这一切，这将削减下来的工作做的一样好
PS: you could also use code generators for all this, this would cut down the work to do as well.
这篇关于使用CLR的UDT的SQL Server存储过程的参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
