我是 ASP.NET MVC 的新手，并继承了一个使用该技术的项目。
这样的 Web 项目包含三个文件夹Views：Controllers和Model. 据我了解，模型实际上包含您的域/业务逻辑，并由您的控制器调用。控制器本身充当视图和模型之间的委托者。
现在，在典型的分层架构中，任何项目中都不应该有对 Web/UI 项目的引用。
我觉得这很令人困惑：
-> UI 包含模型，在理想世界中，模型基于“领域驱动设计”原则。
-> UI 顶部的层（服务和数据访问）不能有对 UI 的引用
如果他们不知道您的模型，您如何编写高效的服务和数据访问层？
我在这里想念什么？Web.Model 是否与“DDD”不同，我是否还应该有一个单独的 BL 项目？如果是这样，那么 Web.Model 应该包含什么？
我将模型视为一个概念。您可以拥有一个包含您的域（您的实体、您的服务等）的完全独立的项目，并在您的“UI”项目中引用它。在这种情况下，这将是您的“模型”。这是我通常做的事情，在我的模型文件夹中，我保留“ViewModels”，用于绑定/验证（用于 UI）。例如，如果我有一个 Employee 但我不想使用它的所有属性（或就此而言不同的属性），我将EmployeeViewModel按照我想要的方式创建一个调整它，我将添加验证（如果需要）和我会将它传递给我的视图。
这绝不是“正确的方式”/“唯一的方式”，但它过去对我有用，我想我会分享（另外，我的解释很糟糕，所以我真的希望这篇文章有道理，如果不需要或需要澄清 - 请告诉我）。
您不一定需要将模型放在同一个项目中。您当然可以将它们放在不同的层中。
这就是我通常设置我的项目的方式
1) UI 项目- 这是一个 MVC Web 应用程序类型的项目，我将在其中拥有我的控制器及其视图和其他与 UI 相关的东西
2）业务实体——这将是一个类库类型项目，我将在其中定义我的域对象（例如：客户）。这看起来与我的数据库模式看起来很相似。这些通常只是代表我的域模式的 POCO（我将其用于 CodeFirst 数据库生成）。
3) 数据访问- 这将是另一个具有数据访问类的类库类型项目。通常我的存储库类/接口、我的 DBContext 类和其他数据访问类将在这个项目中。
4) 测试- 项目的单元测试
已添加业务实体项目作为对数据访问项目的引用，以便我可以在我的数据访问代码中使用这些类。
业务实体和数据访问项目作为参考添加到 UI 项目中。我会从我的 Controllers/Service 类中调用数据访问方法。
您还可以根据需要在控制器和数据访问层之间添加服务/业务逻辑层。
我的 UI 项目 ViewModels 文件夹中也有几个 ViewModel 类。我在某些屏幕上使用它，我必须显示来自多个域对象的数据。我有一个映射/服务类，它将域对象映射到视图模型对象。如果您的项目是 bifg，您可以将其作为一个单独的项目保留在同一解决方案下
提示：您可以使用 EntityFramework（我推荐它，因为它很容易上手）来获取您的数据，并且设置起来非常简单，从而消除了您的 DAL 并节省了您自己编写所有内容的时间。
服务：您可以拥有返回 XML/JSON（其他格式？）的控制器，方法是将您从 DB 获得的数据转换为 XML/JSON 并返回它而不是视图。查看 MVC 4 WebApi 了解更多详细信息，请注意，您也可以使用 mvc 3 进行几乎相同的操作
另请参阅asp.net/mvc站点以获取入门教程，它们非常有用。