存儲庫模式和數據類型返回

Question

我正在使用存儲庫模式，並想知道應該返回哪些數據類型。在我的數據庫中，我有一個可變長度的字符串，需要根據固定長度進行分解。我最初想要傳遞字符串，並讓服務層根據配置列的長度進行解析。我不太喜歡從存儲庫層傳遞一個字符串的想法，寧願傳出一個完整的對象。傳遞字符串似乎沒有足夠的責任分離，但讓存儲庫不得不轉到另一個方法來獲取字符串應該如何解析，並且執行解析似乎對回購有太多的工作。在這種情況下，有什麼應該是回購和服務責任的建議？

Answer 1

由於Repository應該充當內存對象的集合，它應該返回應用程序期望處理的任何類型對象的實例。如果你的應用程序需要一個解析對象，你應該返回它。

無論如何，依靠一些服務來完成解析都是您的基礎設施的一部分。在大多數Repository實現中，在返回之前必須對持久化數據進行一些操作，所以這是一件好事。

例如，如果您的存儲庫正在返回一個域層對象，但您的持久性使用L2S，則可能需要將L2S數據映射到域對象。你需要依賴倉庫以外的東西來做到這一點。把它稱爲服務或其他什麼，你可能不想用存儲庫代碼來映射。

Answer 2

解析方法可能是您的資源庫類中的私有方法，因此隱藏了公共實際回購方法的實際解析。或者，它可能是生活在Util類中的擴展方法。

我認爲你在考慮不把該字符串解析到svc層時是正確的，因爲它似乎違反了SRP。

Answer 3

存儲庫應該肯定會返回業務對象。

至於誰應該做的解析，你可以做很多事情。也許你可以使用助手函數或類似的東西來將字符串解析爲正確的格式。如果它不會在回購之外有用，那麼您可以重構代碼以使其更具可讀性。

你在聲明你不應該讓你的Repository類伸出你的服務層是正確的，所以無論你用什麼重構方法清理存儲庫，它都應該在該層完成，而不是更高。

Answer 4

我的首選選擇是首先不會將數據存儲在固定寬度的分隔字符串中。 :)

我想到的方式是：誰最關心數據的實際存儲？如果字符串格式是某個遺留系統的工件，而不是業務邏輯的重要組成部分（即，如果要更改存儲機制，則會刪除該字符串），然後將其隱藏在存儲庫後面。如果它是數據的重要組成部分，但是您將其從業務邏輯中抽象出來，請將其放入服務中。

如果您確實將其保留在存儲庫中，則可以創建一個特殊的類來處理該字符串並將其作爲接口傳遞給存儲庫。這樣你可以像瘋了一樣單元測試字符串處理代碼（如果需要的話，可以在其他地方重新使用它）並簡化存儲庫。