从分层架构更新DB：最佳方法？

Question

我构建了一个可以使用此DAL检索数据的基本DAL和包含多个对象的业务层。一旦我将数据映射到业务对象并使用它做了一些事情，我还想将数据写回数据库。某些业务对象具有很多属性，因此不可能将业务对象的每个值作为参数传递给相应数据服务的方法。

我一直在考虑的其他方式：

1. 将业务对象传递给相应的数据服务，执行SP并将所有值作为参数。 - 太糟糕了，因为我必须将业务对象传递给DAL（违反分离），并且可能最终得到带有> 50个参数的SP

2. 在业务对象中创建一个空（？）数据集，用业务对象中的值填充它，将该数据集传递给数据服务，并通过dataadapter更新数据库。我想到了创建一个带有“... WHERE 0”-SQL String的空数据集。这会是一个好习惯吗？

这是我第一次这样做。后者对我来说听起来更好，但也许还有其他更好的方法？或者由于某些我不知道的原因，第一个更好？

非常感谢！

[编辑：]我不能使用LinQ2SQL，因为我使用C＃Express（它只支持查询本地数据库，而我的是远程数据库）

Answer 1

将您的对象传递给DAL。如果手动编写DAL层，您的DAL层应该知道如何获取实体并将其持久保存到数据库，以及如何从数据库返回实体。 DAL是关于实体对非易失性介质的持久性。

Answer 2

您尚未提及使用LINQ。那是因为你还没有使用.NET 3.5吗？

此外，您不必使您的DAL成为通用的。您的DAL的调用者不会尝试更新业务对象的所有属性，是吗？他们可能想要更新它的一部分，因此您应该提供一个执行此操作的API。例如，他们可能只想向Contact对象添加地址，甚至可能更新电话号码。您需要在执行调用者真正尝试执行的操作与执行此操作所需的单独方法的数量之间进行权衡。

Answer 3

DAL应该是关于业务对象和特定数据表示之间的映射。这就是使用域对象的Repository模式允许您切换到可能甚至不是数据库的不同持久性实现的原因。

您担心需要向DAL的方法传递太多参数，然后提一个只需要传递2或3个值的示例。如果是这种情况，将其作为方法的参数传递是合理的。如果要传递更多值，则可以通过使用要保存的值子集定义接口来实现它。这样您就可以清楚地指定方法将要处理的信息。

不管上述情况如何，不要让这些方法过于具体，因为你最终会得到许多组合，这些组合会使得它更难以保留。

Answer 4

为什么你认为在将业务对象传递给DAL时，你违反了分离。也许你应该考虑将商务对象分成另一层。

你也可以尝试使用linq2SQL，这样你就可以忘掉参数，这会减少你的SP的数量。

Answer 5

除非您的数据访问层非常通用，否则如何传递业务对象呢？

我喜欢序列化对象并将XML传递给存储过程，但我可能只是少数。