处理SQL参数的最佳方法？
我基本上有一个与任何业务逻辑完全隔离的数据库层。这意味着只要我准备好将某些业务数据提交给数据库，就必须将所有业务属性都传递给数据方法的参数。例如：处理SQL参数的最佳方法？
Public Function Commit(foo as object) as Boolean
这工作得很好，但是当我进入提交并有几十个参数的更新，它可以是一个大量的输入。更不用说，我的两个方法 - 更新和创建 - 采取相同的参数，因为他们基本上做同样的事情。我想知道的是，什么是传递这些参数的最佳解决方案，以便我不必每次更改这两个方法时都更改这些参数，以及减少我的输入:)我想到了一些可能的解决方案。一种方法是将所有sql参数移动到数据类的类级别，然后将它们存储在业务层中设置的某种数组中。任何帮助将是有用的！
感谢您的回复，但我想我已经想出了一个更好的方式来完成我正在做的事情。这与使用upsert类似，但我所做的是使用一种名为Commit的方法来查找给定的主键。如果在数据库中找到该记录，则执行更新命令。如果没有，我做一个插入命令。由于参数相同，因此您不必担心更改它们。
所以基本上你想通过ListParameters？
为什么不重新提交您的Commit函数并让它接受Parameter对象列表？
我在想这是要走的路，但我会等着看有没有人想出别的东西。 – Austin 2009-04-17 19:32:24
如果您在SQL 2008上可以使用合并替换插入/更新杂耍。有时称为upsert。
您可以创建一个struct来保存参数值。
对于你的问题我猜Iterator设计模式是最好的解决方案。通过一个接口实现说ICommitableValues你可以像这样传递一个密钥对枚举值。密钥是列名称，值是列可接受的值。一个属性甚至专用于返回插入这些值和/或存储过程等的表名称。
要保存输入，您可以使用声明性编程语法（属性）来声明可中断的属性和中间件中的主类可以使用反射来提取这些可共享属性的值，并从中准备一个ICommitableEnumeration实现。
你能详细说明你在DAL中的代码吗？你是否将对象传递给DAL方法，然后将参数设置为该对象的属性？ – 2009-04-17 19:43:56
Russ：是的，我正在做这件事，但我传递的对象是本机CLR类型，而不是具有它们自己属性的类对象。 – Austin 2009-04-20 15:58:36