设置没有任何依赖项的 MVC 项目结构的正确方法
Proper way to setup MVC project structure that won't have any dependencies
请看我下面的项目结构。
我的解决方案包含以下内容：
TestProj.WebUI MVC5, Ninject IoC注入BLL
TestProj.WebUI.测试
TestProj.BLL - 包含包含 ICustomerProvider.cs 的 Interfaces 文件夹和包含 CustomerProvider.cs 和 [=40 等类的 CRM、HR 等文件夹=]
TestProj.DAL - EF6 DbFirst，还包含包含 CustomerRepository.cs 的 Repository 文件夹和包含 ICustomerRepository.cs[=10= 的 Interfaces 文件夹]
TestProj.Common - 普通类
我不知道是否还应该在我的 BLL 中添加依赖注入来注入 DAL。
如果您不能模拟 dal 中的对象，则可能很难测试您的 bll，因此我认为使用接口和 di 会很有用。
如果你松散地耦合它，你也可以选择将你的 dal 换成不同的 dal。 dal 的接口可以在 bll 中。
作为一般规则，所有依赖项都应该流向您的 bll，而不是相反。 bll 不应该依赖于任何东西。
关于您的模型，我通常将它与 dal 和 bll 放在一个单独的 class 库中，并且只在 ui 项目中谨慎使用模型文件夹。
一个可能有用的概念是为您的 bll 设置一个外观层。这避免了 ui 必须知道你的 bll 的复杂细节，你只需从你的控制器调用外观。
在我自己的项目中，我有一个 bll 外观层，如果它只是一个数据库访问，则直接通过 dal，或者如果它执行任何逻辑，则直接通过 bll 对象。我的目标是 100% 的测试覆盖率，特别是 bll 对象，并不总是 tdd 其他所有内容（取决于项目要求uirements）。
如果您使用 ef，另一个更有争议的角度是您允许 IQueryable 对象传播多远。我通常将它们保留在 dal 层中只是因为在较大的项目中我不希望我的 bll 依赖于 ef.
我发现微软的应用程序架构guide 2.0刚出来的时候很有用，现在有点老了，但还是很实用的。您可以在 http://msdn.microsoft.com/en-gb/library/ff650706.aspx
找到它
最后，我个人不喜欢 bll 和 dal 这两个术语，因为它们是首字母缩写词，让我想起了我们多年前编写的富客户端软件，我通常称我的 bll 层为逻辑、外观、模型和数据之类的名称而不是数据层中的 dal。
构建解决方案的方法有很多种，但这里有一个基于空 MVC 项目的 VS2013 测试解决方案，带有引用集，说明了我的意思。
希望这对您有所帮助。
请看我下面的项目结构。
我的解决方案包含以下内容：
TestProj.WebUI MVC5, Ninject IoC注入BLL
TestProj.WebUI.测试
TestProj.BLL - 包含包含 ICustomerProvider.cs 的 Interfaces 文件夹和包含 CustomerProvider.cs 和 [=40 等类的 CRM、HR 等文件夹=]
TestProj.DAL - EF6 DbFirst，还包含包含 CustomerRepository.cs 的 Repository 文件夹和包含 ICustomerRepository.cs[=10= 的 Interfaces 文件夹]
TestProj.Common - 普通类
我不知道是否还应该在我的 BLL 中添加依赖注入来注入 DAL。
如果您不能模拟 dal 中的对象，则可能很难测试您的 bll，因此我认为使用接口和 di 会很有用。
如果你松散地耦合它，你也可以选择将你的 dal 换成不同的 dal。 dal 的接口可以在 bll 中。
作为一般规则，所有依赖项都应该流向您的 bll，而不是相反。 bll 不应该依赖于任何东西。
关于您的模型，我通常将它与 dal 和 bll 放在一个单独的 class 库中，并且只在 ui 项目中谨慎使用模型文件夹。
一个可能有用的概念是为您的 bll 设置一个外观层。这避免了 ui 必须知道你的 bll 的复杂细节，你只需从你的控制器调用外观。
在我自己的项目中，我有一个 bll 外观层，如果它只是一个数据库访问，则直接通过 dal，或者如果它执行任何逻辑，则直接通过 bll 对象。我的目标是 100% 的测试覆盖率，特别是 bll 对象，并不总是 tdd 其他所有内容（取决于项目要求uirements）。
如果您使用 ef，另一个更有争议的角度是您允许 IQueryable 对象传播多远。我通常将它们保留在 dal 层中只是因为在较大的项目中我不希望我的 bll 依赖于 ef.
我发现微软的应用程序架构guide 2.0刚出来的时候很有用，现在有点老了，但还是很实用的。您可以在 http://msdn.microsoft.com/en-gb/library/ff650706.aspx
找到它最后，我个人不喜欢 bll 和 dal 这两个术语，因为它们是首字母缩写词，让我想起了我们多年前编写的富客户端软件，我通常称我的 bll 层为逻辑、外观、模型和数据之类的名称而不是数据层中的 dal。
构建解决方案的方法有很多种，但这里有一个基于空 MVC 项目的 VS2013 测试解决方案，带有引用集，说明了我的意思。
希望这对您有所帮助。