我的上一个应用程序实现了 UoW、DI、IoC、存储库模式、工厂,以及各种看起来很整洁的东西,但让维护和调试变得很痛苦。
我对我最近的应用程序采取了相反的方法——没有 DI、没有 IoC、没有 UoW,只有 MVC、服务层和 DB。我可能认为存储库模式全错了,但我所做的阅读表明它只负责 Db 访问,而不是业务逻辑,以保持这两个问题分开。
在实现存储库模式时,我觉得我只是在复制我的很多服务层。例如,在我的 UserService 类中,我有以下内容:
public void UpdateAboutMe(AboutMeDto request)
{
using (var db = CreateContext())
{
var user = db.Users.FirstOrDefault(s => s.Username.Equals(request.Username, StringComparison.OrdinalIgnoreCase));
if (user != null)
{
user.AboutMe = request.AboutMe;
SaveChanges(db);
}
else
{
throw new InvalidDataException("Null User");
}
}
}
这样,服务获取对象,更新单个字段,并将更改提交到数据库,并释放上下文。
在我的 UserService 中,我还有其他类似的方法:
- 按用户名获取用户
- GetUserById
- GetUsersWithChildEntity
- GetUsersWithoutChildEntities(比前者更快,对吧?)
- 更新用户缩略图
- 更新用户生物
- 更新用户兴趣
难道不是每一个都需要相应的 Repo 方法吗?
如果我实现一个存储库方法,上述服务可能如下所示:
public void UpdateAboutMe(AboutMeDto request)
{
return _userRepository.UpdateAboutMe(request);
}
这看起来更干净,但不是更干净,因为我只是在移动东西 - 如果我决定更改我的一个 Get 方法以包含一些子实体,我现在必须在 Repo 中创建另一个方法,更新接口,并更新服务方法,而不是直接从我的服务方法中进行。
基于我上面展示的有限理解,我基本上有兴趣了解我是否应该实施存储库模式。似乎它要么为您的应用程序增加了一个垂直层的复杂性,要么只是让您的服务层更加强大。
IMO - 使用 EF 延迟加载和按字段更新 - 存储库模式似乎需要更多开销。
而且,在这种情况下,我对 TDD 并不感兴趣,所以如果可能的话,我希望将可测试性排除在外。