我有以下服务类:
public class JobService {
private UserService us;
public JobService (UserService us) {
this.us = us;
}
public void addJob(Job job) {
// needs to make a call to user service to update some user info
// similar dependency to the deleteUser method
}
}
public class UserService {
private JobService js;
public UserService(JobService js) {
this.js = js;
}
public void deleteUser(User u) {
using (TransactionScope scope = new TransactionScope()) {
List<IJob> jobs = jobService.findAllByUser(u.Id);
foreach (IJob job in jobs) {
js.deleteJob(job);
}
userDao.delete(user);
scope.Complete();
}
}
}
这些服务类中的每一个都由 IoC 容器实例化,并且没有功能问题,但是对我来说,这种方法存在潜在的设计缺陷,我想知道是否有更有意义的替代方法。
最佳答案
正如有人已经指出的那样,问题不在于 DI 容器的限制,而在于您的设计。
我明白你有一个单独的 UserService
的原因和 JobService
其中包含对彼此的引用。这是因为 UserService
和 JobService
包含一些需要其他服务作为引用的逻辑(添加作业需要添加用户等)。但是,我认为您不应该从另一项服务中引用一项服务。相反,您应该在服务后面有另一个抽象层,这些服务将用于公共(public)逻辑。因此,服务将包含不能(不应该)重用的逻辑,而助手将包含共享逻辑。
例如:
public class UserHelper{
//add all your common methods here
}
public class JobService {
private UserHelper us;
public JobService (UserHelper us) {
this.us = us;
}
public void addJob(Job job) {
// calls helper class
}
}
public class UserService {
public UserService(UserHelper js) {
this.js = js;
}
public void deleteUser(User u) {
// calls helper class
}
}
这样,循环引用就不会有任何问题,并且您将拥有一个包含需要由不同服务重用的逻辑的地方。
此外,我更喜欢拥有彼此完全隔离的服务。
关于c# - 依赖注入(inject)架构设计 - 服务类循环引用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14042645/