將構建器方法與服務方法相結合 - 不好的做法？

Question

這是一個通用模式/最佳實踐問題。 我正在使用 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屬性來解決這個問題，該屬性可以在應用程序啟動或測試設置時進行配置，並表示應該記錄/偽造服務調用呢？

從純粹主義者的角度來看，除了可測試性之外，第二種方法有什么“錯誤”嗎？ 我實際上正在討論是否在我正在開發的幾個庫中執行此操作，我的主要危險信號是第一種方法似乎更常見。

Answer 1

我認為第二種方法很好，只要公共 API 類只關心提供流暢的接口並正確地委派工作。

Answer 2

我實際上打算在我的微型 orm 的下一個版本中采用第二種方法。 我沒有想到可測試性會受到影響，現在考慮一下，我認為不會。 因為流暢的構建器只是一個外觀，至少最后一部分我可能會將它實現為易於測試的擴展方法