EF：实体是否应该具有业务逻辑？

我在想，实体是否有能力保存对上下文的更改？或者是否有与该特定实体相关的业务逻辑？例如：EF：实体是否应该具有业务逻辑？

ActionResult ResetPassword(UserViewModel viewModel) 
{ 
    var user = userCollection.GetUser(viewModel.Username); 
    user.ResetPassword(); 
}

其中：

class User : Entity 
{ 
     public string Password{ get; set; } 

     public ResetPassword() 
     { 
      Password = "" 
      context.SaveChanges(); 
     } 
}

我觉得这有点不可思议，因为该实体将有上下文的参考。我不确定这是否会起作用 - 或者这是否被推荐。但我想在一个不需要担心更高级别保存更改的域中工作，我该如何实现这一目标？

谢谢！

更新

我已经更新了我的例子 - 希望它更清楚一点，现在:)

来源

2012-08-17 Karan

我会保持我的实体为POCO的（普通老式类对象，只有属性的类）和有一个Repositary做插入/更新方法。

我可以将我的实体放在单独的类库中，并在不同的地方（甚至在不同的项目中）使用它，并使用不同的Repository实现。

在this教程这是很好的解释，如何做一个Repositary &单元的工作模式上它使用实体框架的MVC项目

来源

2012-08-17 12:18:11 Shyju

这很有趣。看，我有一个不同的想法。我认为域对象应该具有@Steven提到的行为。我认为模型是有效的实体 - 比如User。也许更好的例子是 - 用户是否可以重置密码。我原以为这是用户的责任，而不是仓库的责任。你觉得Shyju/Steve怎么样？ – Karan 2012-08-17 14:28:53

http://en.wikipedia.org/wiki/Anemic_domain_model – Karan 2012-08-17 14:46:14

http://msdn.microsoft.com/en-us/library/ff649690.aspx – Shyju 2012-08-17 14:51:27