我已经构建了一个基本的 DAL，它可以使用这个 DAL 检索数据和一个包含多个对象的业务层。一旦我将数据映射到业务对象并对其进行了处理，我还想将数据写回数据库。一些业务对象有很多属性，因此将业务对象的每个值作为参数传递给相应数据服务的方法是不可能的。
我一直在考虑的其他方式：
将业务对象传递给相应的数据服务，在那里执行一个将所有值作为参数的 SP。- 糟透了，因为我必须将一个业务对象传递给 DAL（违反分离）并且可能最终得到具有 >50 个参数的 SP
在业务对象中创建一个空 (?) 数据集，用业务对象中的值填充它，将该数据集传递给数据服务并通过数据适配器更新数据库。我想用“... WHERE 0”-SQL 字符串创建一个空数据集。那会是一个好习惯吗？
这是我第一次做这样的事情。后者对我来说听起来更好，但也许还有其他更好的方法？或者由于某些我不知道的原因，第一个更好？
非常感谢你！
[编辑：] 我不能使用 LinQ2SQL，因为我使用 C# Express（它只支持查询本地数据库，而我的是远程数据库）
将您的对象传递到您的 DAL。如果您手动编写 DAL 层，您的 DAL 层应该知道如何获取实体并将其持久保存到数据库，以及如何从数据库返回实体。DAL 是关于您的实体对非易失性介质的持久性。
您还没有提到使用 LINQ。那是因为您还没有使用 .NET 3.5 吗？
此外，您不必使您的 DAL 通用。DAL 的调用者不会尝试更新业务对象的所有属性，是吗？他们可能想要更新其中的一部分，因此您应该提供一个执行此操作的 API。例如，他们可能只想将地址添加到联系人对象，或者甚至可能更新电话号码。您需要在执行调用者真正尝试执行的操作与执行此操作所需的单独方法的数量之间进行权衡。
DAL 应该是关于您的业务对象和特定数据表示之间的映射。这就是为什么使用域对象的存储库模式允许您切换到不同的持久性实现，甚至可能不是数据库。
您担心需要向 DAL 的方法传递太多参数，然后举一个示例，您只需要传递 2 或 3 个值。如果是这种情况，将其作为方法的参数传递是合理的。如果要传递更多值，实现它的一种方法是定义一个包含要保存的值子集的接口。这样，您就可以清楚地指定该方法将处理的信息。
不管上述情况如何，不要让方法过于具体，因为你最终会得到很多组合，这会使维护变得更加困难。
为什么您认为将业务对象传递给 DAL 时违反了分离。也许您应该考虑将业务对象分离到另一层。
你也可以尝试 linq2SQL，这样你就可以忘记参数，这将减少你的 SP 的数量。
除非您的数据访问层非常通用，否则传递业务对象会很糟糕吗？
我喜欢序列化对象并将 XML 传递给存储过程，但我可能是少数。