假设您有实体，服务层和存储库（使用NHibernate之类的ORM）。 UI与服务层交互。
哪种类型的代码适合于服务层？
仓库协调？
看起来像entities should not reference the repository，因此在服务层中应该存在对加载/保存/移出实体的调用吗？
涉及存储库的业务逻辑？
如果上述条件是正确的，是否应该在服务层中执行类似检查用户名是否不同的操作（即调用GetUsersByUsername并检查结果）？在建议数据库应处理不同的问题之前，如何验证90天内未使用密码？
涉及多个实体的业务逻辑？
我不确定这一点，但要说您有必要对一组可能相关或不相关且实际上不适用于单个实体的实体进行操作。实体是否应该能够在这些集合上进行操作，或者这种事物是否属于服务层？
映射？
无论您使用DTO还是将实体发送到服务层或从服务层发送实体，您都可能会结束映射（最好使用AutoMapper）。这是否属于服务层？
我正在寻找对以上列出的想法以及与实体/存储库一起使用时有关服务层职责的其他任何想法的确认（或拒绝）。
最佳答案
仓库协调？
总根应该划定交易边界。因此，应该很少涉及多个存储库。如果它们是-通常在创建新的聚合根（而不是修改其状态）时发生。
涉及存储库的业务逻辑？
是的，检查用户名是否不同可能存在于服务层中。因为用户通常是一个聚合根，并且聚合根存在于全局上下文中（没有任何东西可以“保留”它们）。我个人将这种逻辑放在存储库中，或者只是直接通过ORM检查。
至于检查密码使用情况-这是用户本身的关注点，应位于User对象下面。像这样：
class User{
void Login(){
LoggedOn=DateTime.Now;
...
}
bool HasLoggedInLast90Days(){
return (DateTime.Now-LoggedOn).Days<=90;
}
}
涉及多个实体的业务逻辑？
聚合根应管理其实体集合。
class Customer{
void OrderProduct(Product product){
Orders.Add(new Order(product)); //<--
}
}
但是请记住，聚合根不应微控制其实体。
例如。这不好：
class Customer{
void IsOrderOverdue(Order order){
return Orders.First(o=>o==order)....==...;
}
}
而是使用：
class Order{
void IsOverdue(){
return ...;
}
}
映射？
我想映射到dto生活在服务层。我的映射类位于Web项目中的视图模型类旁边。