把构建器方法和服务方法结合起来——不好的做法

这是一个通用的模式/最佳实践问题。我正在使用c#，但我认为它同样适用于Java和其他环境。对于库来说，公开一个与面向服务的类密切相关的构建器类是很常见的。假设一个允许您这样做的ORM:

var sql = SQLBuilder.Select("*").From("Users");
var users = db.ExecQuery<User>(sql);

作为库开发人员，很容易将它们组合成一个更流畅、更容易发现的API，只需要关注一个对象:

var users = db.Select("*").From("Users").ExecQuery<User>();

请注意，差异严格是在API表面;在底层，我们仍然会有多个具有适当关注点分离的类。

第二种方法的一个潜在缺点是可测试性。在第一种方法中，存根服务对象要容易得多。但是，如果库开发人员通过暴露某种静态TestMode属性来处理这个问题，该属性可以在应用程序启动或测试设置时配置，并且信号表明服务调用应该被记录/伪造?

从纯粹主义者的角度来看，除了可测试性之外，第二种方法有什么"错误"吗?实际上，我正在讨论是否在我正在开发的几个库中这样做，我的主要危险信号是，第一种方法似乎更常见。