當您使用實現UnitOfWork模式（NHibernate的會話，實體框架的ObjectContext等）的ORM時，有兩種類型的數據服務方法：保存/提交更改的方法以及僅修改模型屬性的方法。數據服務方法命名
在一段時間內，很難支持這個混亂：當你調用一個方法時，你不確定，它是否會保存更改（如果它不需要在某些外部方法中執行）。
我該如何解決這個問題？我唯一的想法是一個特殊的命名。例如，用於保存方法的AddCustomer和用於非保存方法的FillForAddCustomer。任何其他想法？
有幾種方法可以解決這個問題，而且每種方法都有各自的優點和缺點。
第一種方法是按照您的建議來處理「持久」方法和「未持久」方法之間的區別。 Ruby通過使用感嘆號（!）結束方法名稱來指示「危險」方法（即那些修改它們被調用的對象或它們的參數的方法）的類似方法。根據你的發展文化，這樣一個約定可能工作得很好，或者它可能不會。我對這樣的約定有個問題，那就是我必須記住另外一件事，很難檢查一致性，而對於那些不熟悉約定的代碼庫的人來說，這是不太明顯的。
解決此問題的另一種方法是使用Command Query Responsibility Segregation（CQRS）模式。這裏的想法是，對於既需要獲取持久化對象又需要保留新對象或更新對象的域對象，而不是有一個Repository，則將這兩個責任分開。除了更清楚哪些方法會持續存在（您正在使用來自完全不同名稱空間的類）之外，您還將閱讀與書寫分開，從而可以更輕鬆地調整應用程序以獲得更好的性能。
有些人可能會爭辯說，爲了簡單地知道哪些方法持續存在，哪些不存在，CQRS與命名約定是一樣的，只是向上移動了一層。雖然這在某種程度上是正確的，但通過將慣例提升到命名空間級別而不是方法名稱級別，您可以通過依賴關係圖更好地跟蹤，如果您與持續發生的位置不一致並允許您更容易重構。