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

這是一般模式/最佳實踐問題。我使用C＃，但我認爲它同樣適用於Java和其他環境。圖書館公開一個與更多面向服務的類相關的構建器類是很常見的。以一個假想的ORM，可以讓你做到這一點：將生成器方法與服務方法相結合 - 不好的做法？

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

：

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

作爲一個庫開發這是很有誘惑力的這些，只有一個對象結合成一個更加流暢，發現API去關注請注意，差異嚴格在API表面;在引擎蓋下，我們仍然有多個類別，關注點分開。

第二種方法的一個潛在缺點是可測試性。在第一種方法中，存儲服務對象更容易。但是，如果庫開發人員通過公開某種可在應用程序啓動或測試設置中配置的靜態TestMode屬性來處理此問題，並表示服務調用應該被記錄/僞造？

從純粹的角度來看，除了可測試性之外，第二種方法有什麼「錯誤」嗎？我實際上正在辯論是否在我正在研究的幾個圖書館中這樣做，而我的主要標誌是第一種方法似乎更常見。

來源

2014-03-25 Todd Menier

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

來源

2014-03-25 21:47:56

我真的打算採取第二種方法爲我的微型ORM的下一個版本。它並沒有出現在我的腦海裏，可測試性會受到影響，現在正在考慮它，我認爲它不會。因爲這個流利的構建器只是一個外觀，至少最後一部分我可能會實現它作爲一個易於測試的擴展方法

來源

2014-03-25 22:53:49 MikeSW

你不認爲從圖書館消費者的角度來看可測性會受到一點影響？在第一種方法中，您可以簡單地完全刪除數據庫。但對於第二種方法，您可能必須進行更多模擬設置工作，以至少確保這些構建器方法返回非空值。我想這是多麼乏味的事，取決於你的嘲弄框架。（如果你使用的是Moq，'SetReturnsDefault'可能會有用。） –

不用說，謝謝你的信任投票 - 感覺更好地推進方法2. –

我不這麼認爲，因爲簡單的事實他們不應該首先測試_your_代碼。我也不認爲他們應該嘲笑分貝，應該嘲笑倉庫。但是，在處理持久性時，這是一個特定的問題，但我認爲它並不適用於整體流暢的構建器模式，因此它取決於上下文：D – MikeSW

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

回答

相關問題