服務層與助手對象？

Question

我想就某個具體案例發表您的意見。這是關於服務層與輔助對象 - 而且我不是在尋找理想化的模式，而只是很好地理解我親愛的編程同事對此的看法：

在我當前的應用程序中，我有一個完整的域模型Linq to Sql，非常輕量級的存儲庫，然後使用IQueryable的擴展方法<>根據業務需求過濾/排序/排序），然後包含基於責任分組的服務的服務層，例如IRegistrationService（註冊用戶，登錄名的可用性等）

現在的警告。我也有一些類似加密的「助手」類，並且我還在該目錄中填充了其他不可用的元素（例如自定義枚舉等）。

我需要創建一個新的類，它將處理爲我的應用程序生成自定義鏈接，這比僅使用不同對象並考慮其屬性的String.Format更多。內部工作是無關緊要的。然而，我現在很難實例化某種類型的「LinkService」，因爲我會完成這些工作 - 當我完成後，我覺得最終會有100個服務（及其接口+實現）。

同時我不想在我的「Helpers」命名空間/目錄（例如LinkManager）中創建一些類和其他東西的鬆散混合。

怎麼辦？你們在哪些地方放置了仍然有點商業層次的東西，但同時又如何限制商業/服務層中的商品數量？你在哪裏堅持所有這些小助手類，如簡化和管理會話訪問的中間對象（我假設你想要這種強類型 - 至少我是這樣做的）？

讓我知道您的想法？謝謝 ！

Answer 1

對我來說，使用正確的工具來完成工作是關鍵。如果您需要某種設施來生成鏈接，這基本上是實體屬性到格式化字符串的映射，然後編寫一個工具來執行此操作。它不一定是一種服務......相反，爲這樣的事情提供全面的服務可能是矯枉過正的。但是，我不會把這一點變成你的一般「助手」。這聽起來像是有某種特定目的和意圖的東西，背後有一種特定的行爲。因此，把它放在適合這種行爲的地方......即使這是一個新項目。

我儘量不要在我的應用程序中使用大量的「通用」代碼。一切都有目的並實現特定的行爲。有時候這種目的和行爲是高度可重用的，但我仍然嘗試從邏輯上組織那些可重用的元素。從一個高的水平，我看到我的大多數應用程序分爲以下幾種：

1. 客戶
2. API /服務
3. 域
4. 數據訪問（可選）
5. 框架

許多這種可重用的功能都屬於框架和域之間的一個下級區域。它的一部分可能作爲框架中的一些基類和/或接口和支持類型存在，而另一半，具體實現則存在於我的域中。它有時看起來很奇怪，但以這種方式組織起來可以幫助我儘可能地保持域名清晰（專注於業務問題），同時仍然允許我將通用和可重用概念抽象爲較低級別的「框架」類型。