应用错误收集

如果你不能模拟dal中的对象，可能很难测试你的bll，所以在我看来使用接口和di会很有用。

如果您松散地结合它，您还可以选择更换dal以获得不同的dal。 dal的接口可以在bll中。

作为一般规则，所有依赖项应该流向您的bll，而不是相反。 bll不应该依赖于任何东西。

关于你的模型，我通常将它放在一个单独的类库中，与dal和bll一起使用，并且只使用ui项目中的模型文件夹。

一个可能有用的概念是为你的bll设置一个外观层。这可以防止ui必须知道你的bll的复杂细节，你只需从你的控制器调用外观。

在我自己的项目中，我有一个bll外观层直接进入dal，例如它只是一个数据库访问，或者如果它执行任何逻辑，则是一个bll对象。我的目标是对bll对象进行100％的测试覆盖，并不总是对其他所有内容进行测试（取决于项目要求）。

如果使用ef，另一个更有争议的角度是你允许IQueryable对象传播的距离。我通常只在dal层中保留它们，因为在较大的项目中我不希望我的bll依赖于ef。

我发现Microsoft应用程序架构指南2.0在它出现时非常有用，它现在有点陈旧但仍然相当相关。您可以在http://msdn.microsoft.com/en-gb/library/ff650706.aspx

找到它

最后我个人不喜欢bll和dal这两个术语，因为它们是缩写词，让我想起几年前我们用过的富客户端软件，我通常把我的bll层逻辑，外观，模型和名称称为数据，而不是dal在数据层中。

构建解决方案有很多种方法，但这里有一个基于空MVC项目的VS2013测试解决方案，其中包含参考集，说明了我的意思。

希望这有帮助。