数据服务方法命名

时间:2011-09-01 12:06:26

标签: .net orm unit-of-work

当您使用实现UnitOfWork模式的ORM(NHibernate的Session,Entity Framework的ObjectContext等)时,有两种类型的数据服务方法:保存/提交更改的方法和仅修改模型属性的方法。

在某些时候,很难支持这个混乱:当你调用一个你不确定的方法时,它是否会保存更改(如果你不需要在某些外部方法中执行它)。 / p>

我该如何解决这个问题?我唯一的想法是一个特殊的命名。例如,AddCustomer用于保存方法,而FillForAddCustomer用于非保存方法。还有其他想法吗?

1 个答案:

答案 0 :(得分:1)

有几种方法可以解决这个问题,它们各有各的利弊。

第一种方法是做一些你建议的事情,并通过约定处理“持久”方法和“非持久”方法之间的区别。 Ruby通过使用感叹号(!)结束方法名称,通过指示“危险”方法(即修改调用它们的对象或其参数的方法)采用类似的方法。根据您的发展文化,这样的惯例可能会很好,或者可能不会。我对这类约定的问题是,我需要记住的另一件事是,难以检查一致性,对于新约存在约定的代码库的人来说不那么明显。

解决问题的另一种方法是使用Command Query Responsibility Segregation(CQRS)模式。这里的想法是,不是让一个域Repository用于获取持久化对象,并持久保存新的或更新的域对象,而是将这两个职责分开。除了更清楚哪些方法持久化(你使用来自完全不同的命名空间的类)之外,你还将阅读与写作分开,这样可以更轻松地调整应用程序以获得更好的性能。

有些人可能会争辩说,为了简单地知道哪些方法持续存在而哪些方法不存在,CQRS与命名约定相同,只是提升了一个级别。虽然这在某种程度上是正确的,但通过将约定移动到命名空间级别而不是方法名称级别,您可以通过依赖关系图更好地跟踪是否与持久性发生的位置不一致并允许您更轻松地重构。