当您使用实现 UnitOfWork 模式（NHibernate 的 Session、Entity Framework 的 ObjectContext 等）的 ORM 时，有两种类型的数据服务方法：保存/提交更改的方法和仅修改模型属性的方法。
有时很难支持这种混乱：当您调用一个方法时，您不确定它是否会保存更改（如果不需要，您需要在某些外部方法中这样做）。
我该如何解决这个问题？我唯一的想法是一个特殊的命名。例如，AddCustomer 用于保存方法，FillForAddCustomer 用于非保存方法。还有其他想法吗？
【问题讨论】：
标签： .net orm unit-of-work
有几种方法可以解决这个问题，它们各有优缺点。
第一种方法是按照您的建议执行操作，并通过约定处理“持久”方法和“非持久”方法之间的区别。 Ruby 采用与方法类似的方法，通过以感叹号 (!) 结束方法名称来指示“危险”方法（即修改被调用对象或其参数的方法）。根据您的开发文化，这样的约定可能会非常有效，也可能不会。像这样的约定我遇到的问题是，我还必须记住一件事，很难检查一致性，而且对于代码库的新手来说，约定的存在不太明显。
解决问题的另一种方法是使用Command Query Responsibility Segregation (CQRS) 模式。这里的想法是，不是为一个域对象设置一个Repository 来处理获取持久化对象和持久化新的或更新的对象，而是将这两个职责分开。除了更清楚哪些方法可以持久化事物（您正在使用来自完全不同的命名空间的类）之外，您还将读取与写入分开，这允许更轻松地调整应用程序以获得更好的性能。
有些人可能会争辩说，为了简单地了解哪些方法持续存在，哪些方法不存在，CQRS 与命名约定相同，只是提升了一个级别。虽然这在某种程度上是正确的，但通过将约定提升到命名空间级别，而不是方法名称级别，您可以通过依赖关系图更好地跟踪，如果您与持久化发生的位置不一致并允许您更容易重构。
【讨论】：