我希望得到您的意見的建築風格的一點：OO編碼 - 是否使用對象管理器？
我的ORM給了我一個用戶對象，它對應於我的系統的用戶。我想開發一些用於處理用戶的方法 - GetByUsername（），Authenticate（），VerifyLoginPassword（）等。然而，我覺得其中的一些方法並不屬於User類 - 例如GetByUsername（）至少感覺像User的一個靜態方法，但是如果有另一個類，比如說「UserManager」爲我們提供這些用戶管理類型的任務，它會不會更「乾淨」？對於User實例來說，包含Authenticate（）方法似乎有點奇怪，例如，如果它是進行身份驗證的安全系統？
我擔心的是我最終追隨這個模型到User類不過是一個結構，而我的用戶管理器和安全管理器類實際上完成了所有的方法工作。讓所有這些管理器類操作輕量級對象並不覺得「OO」。
對於這個哲學問題的任何想法或現有技術的鏈接將不勝感激！
這聽起來像是你在這一點上，你正在超越定義對象爲「狗是，一個動物」，並移動到對象定義中的角色，責任條款和行爲。
我會推薦這本書，以幫助您作出這樣的轉變，真正「得到它」：
Object Design: Roles, Responsibilities, and Collaboration
我沒有回答您的具體問題，因爲它是這樣一個根本設計決定，你真的應該瞭解「更大的圖景」。本書將爲您在責任驅動設計的原則和技巧方面提供良好的基礎。
享受，
羅伯特C. Cartaino
您所描述的情況與對象是否遵循自助服務或適配器模式以保存到存儲庫（即數據庫）相關。
自助服務將有對象保存「自己」，如myObjectInstance.Save()，而適配器模式將是myObjectAdapter.Save(myObjectInstance)。
適配器表單通常受到青睞，因爲它從對象中刪除了任何存儲庫功能。
你爲什麼把它叫做適配器？它與此適配器模式有什麼共同之處嗎？ http://en.wikipedia.org/wiki/Adapter_pattern – 2009-07-08 01:46:54
Martin Fowler有一些有用的views on this。
服務定位器和依賴注入之間的根本選擇。第一點是這兩個實現提供了基本的解耦，這在初始示例中是缺少的 - 在這兩種情況下，應用程序代碼都獨立於服務接口的具體實現。這兩種模式之間的重要區別在於如何將該實現提供給應用程序類。使用服務定位器，應用程序類會通過消息向定位器明確要求。通過注入沒有明確的請求，服務出現在應用程序類中 - 因此控制反轉。
控制的倒置是框架的一個共同特徵，但它的價格是有限的。當您嘗試調試時，它往往難以理解並導致問題。所以總的來說，我寧願避免它，除非我需要它。這並不是說這是一件壞事，只是我認爲它需要通過更直接的選擇來證明自己的合理性。
可以繼續重構所有的功能你的用戶類的，但正如你所說，你可能最終什麼也沒有留下它。此時，您可以選擇評估您創建的所有其他類，然後對這些類中的每個類進行單獨判斷，並根據具體情況確定這些類是否包含足夠的功能以保證全新的類。
如果您認爲其中一些類是太小了，然後你可以把它們的功能回到User類。例如，我在User上看到了一個Validate函數，沒有看到任何錯誤，而不是隻有一個方法的UserValidation類。
讓所有這些管理器類操作輕量級對象並不覺得很「OO」。
我不知道這是不是很「OO」，但對我來說感覺很MVC和關注類分離 - 的 - 。擁有非常輕量級的業務類（就其而言，它們只是數據容器），然後存儲庫對象將它們移動是一種常見模式。
我認爲你的錢的時候，你說，這些方法可能無法在用戶對象上的歸屬。獲取/搜索/保存方法可以辯論，但我認爲他們不應該對業務對象自己和應接受的儲存庫（Repository模式）來完成，或者通過Query Objects如果你不希望在存儲庫中將您的ORM抽象出來。
至於認證推移，這將是最好有一組類，一個負責認證和完全脫離其關閉用戶對象。這組類可以意識到用戶對象，或者更好的是他們應該知道諸如證書的契約。
我喜歡把這種以不同的方式。由於沒有業務邏輯涉及，這些方法並不屬於域。我想用命令和查詢隔離原則
GetByUsername（） - 它的一個查詢這確實不需要任何業務邏輯
進行身份驗證（），VerifyLoginPassword（） - 這些都是不應該的驗證邏輯在域做。請參閱本文件Set Based validation in Domain
我的天啊，那是一本昂貴的書。 – 2014-04-22 22:38:12