什么类型的代码适合服务层？
存储库协调？
它看起来像entities should not reference the repository所以应该在服务层中存在加载/保存/驱逐实体的调用吗？
涉及存储库的业务逻辑？
如果上述情况属实,那么检查用户名是否不同就应该进入服务层(即调用GetUsersByUsername并检查结果)？在建议数据库应该处理不同之前,如何验证密码是否在90天内未被使用？
涉及多个实体的业务逻辑？
我不确定这个,但是你说你需要对一组实体进行操作,这些实体可能相关或不相关,并且不适用于单个实体.实体是否应该能够对这些集合进行操作,或者这类内容是否属于服务层？
映射？
无论您是使用DTO还是将服务层发送到服务层,您都可能最终映射(最好使用AutoMapper).这属于服务层吗？
我正在寻找确认(或拒绝)上面列出的想法,以及在使用实体/存储库时有关服务层职责的任何其他想法.
Repository Coordination?
聚合根应该绘制事务边界.因此 – 很少涉及多个存储库.如果它们 – 通常在您创建新聚合根时发生(而不是修改其状态).
Business Logic that Involves Repositories?
是的,检查用户名是否不同可能存在于服务层.因为用户通常是聚合根,并且聚合根存在于全局上下文中(没有“持有”它们).我个人将这种逻辑放在存储库中或直接通过ORM检查.
至于检查密码使用情况 – 这是用户自己关注的问题,应该存在于User对象下面.像这样的东西：
class User{
void Login(){
LoggedOn=DateTime.Now;
...
}
bool HasLoggedInLast90Days(){
return (DateTime.Now-LoggedOn).Days<=90;
}
}
Business Logic that Involves Multiple Entities?
聚合根应该管理它们的实体集合.
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 ...;
}
}
Mapping?
我想映射到dto的live in service层.我的映射类位于Web项目中的视图模型类旁边.