我有3个项目文件
webui - controllers and views
framework - service layer and repos
tests- unit tests
所以我看到我的控制器只会与我的服务层(包含我的业务逻辑)对话。服务层将与repos通信并获取数据库数据。
我的回购只会谈论数据库并返回数据。
现在,如果我想对其进行单元测试,我需要使用假的服务层和假存储库。
这样我就可以孤立地测试控制器和服务层。
那么我在哪里将我的ninject代码放在我的框架类库中,以便我可以将它与我的服务层一起使用?
修改
史蒂文,你说我应该做这样的事情//使用mvc扩展名在全局aspx中设置ninject
//现在绑定东西
private class SportsStoreServices : NinjectModule
{
public override void Load()
{
Bind<IAdminService>().To<AdminService>();
Bind<IAdminRepo>().To<AdminRepo>();
}
}
// controller
public class AccountController : Controller
{
//
// GET: /Account/
private IAdminService adminService;
public AccountController(IAdminService adminService)
{
this.adminService = adminService;
}
public ActionResult Login()
{
var getAllAdmins = adminService.GetAllAdmins();
return View();
}
}
//服务层
public class AdminService : IAdminService
{
private IAdminRepo adminRepo;
public AdminService(IAdminRepo adminRepo)
{
this.adminRepo = adminRepo;
}
public List<Admins> GetAllAdmins()
{
return adminRepo.GetAllAdmins();
}
}
//Repo
public class AdminRepo : IAdminRepo
{
public List<Admins> GetAllAdmins()
{
// some query to get all admins
}
}
答案 0 :(得分:5)
当您正确地(并且完全地)遵循依赖注入模式时,您需要引用IoC容器的唯一位置是您的应用程序根目录(在您的情况下是您的Web项目)。对于MVC,您通常会有ControllerFactory
知道如何使用您的特定IoC框架创建新控制器。您的控制器将围绕构造函数注入进行设计,因此您的IoC框架能够自动注入所有依赖项。您通常会在整个项目中使用构造函数注入。这允许您让其余的代码不知道选择的IoC实现。
对于单元测试,通常使用构造函数注入来手动注入依赖项。这使您无需为单元测试配置IoC框架。在测试项目中使用IoC库很痛苦,因为您经常希望每个测试用例返回不同的依赖项,并且测试框架通常并行运行测试。最好是不在测试中使用任何IoC框架,但是自己调用被测试类型的构造函数。
使用DI进行单元测试的技巧是保持单元测试的可维护性。例如,您可以通过将测试中的类型的创建提取到工厂方法中来执行此操作。这允许您在代码中的一个位置调用此类构造函数。当构造函数更改时,您将不得不在一个位置更改测试代码。我从书中The Art of Unit Testing学到了很多关于编写可维护单元测试的知识。我可以推荐它。
答案 1 :(得分:1)
在项目中,DI应该位于对象组合可能发生的位置。例如,在WCF服务项目中,我们可以使用IInstanceProvider,IN asp.net Global.asax来完成。 基本规则:确保DI是应用程序启动点