我需要对 MVC 架构和三层架构进行一些说明答案

【问题标题】：I need some clarification on the MVC architecture and the three-tier architecture我需要对 MVC 架构和三层架构进行一些说明
【发布时间】：2010-11-04 18:08:21
【问题描述】：

我一直在阅读 Pro ASP NET MVC Framework 这本书，我对很多事情感到非常困惑。我一直在尝试做一些研究，但我发现有这么多不同的方法和概念被扔给我，这只会让事情变得更糟。
所以我有几个问题：

我知道 MVC 应该将功能分为三个主要部分：模型 -> 控制器 -> 视图。 MVC 是不是与三层架构不同的方法？还是我还应该考虑在我的项目中创建数据访问层和业务逻辑层？
什么是存储库？它是什么充当我的数据访问层？存储库在哪里/如何适合 MVC？
这本书谈到了使用 LINQ to SQL 与数据库进行交互，但它指出未来将不支持 LINQ to SQL，并且 Microsoft 正在为实体框架放弃它。实体框架在哪里适合 MVC，我如何与之交互？

提前感谢您的帮助！
马特

【问题讨论】：

LINQ to SQL ~NOT~ 被删除了，它在你关于 Pg 的书中陈述了很多。 49.
另外，关于MVC和三层的区别，我建议你重新阅读pg。 41 特别是顶部的最后一段。
我确实看到它将包含在 ASP.NET 4.0 中，但我认为它仍在慢慢被删除。好的，是的，我确实读过那一段。就像我说的那样，所有的术语和概念一下子被扔给我，我有点困惑，忘记了我读过的一些东西。谢谢。
@Matt，我想说这不是该领域真正初学者的最佳书籍。并不是说它不是一本好书，我真的很喜欢它。但是“Pro ASP.NET MVC”就是这样，一本更适合退伍军人的书。我想如果我过去没有被多次介绍这些概念，我也会感到困惑。
@Matt，LINQ 将长期陪伴我们。实体很好，但并不是大多数人无论如何都不会使用 LINQ to Entities，所以学习和使用 LINQ 根本不是一个坏选择。

标签： asp.net asp.net-mvc linq-to-sql repository-pattern 3-tier

【解决方案1】：

MVC 主要是表示层的一种模式，它侧重于视图和控制器之间的交互。模型可以认为是the components of the application that are responsible for maintaining state，包括持久化。

在一个简单的应用程序中，模型可能只是一个 LINQ-To-SQL 模型。在大型企业应用程序中，模型可能包含数据访问层、业务层和领域层。 ASP.NET MVC 并不限制您应该如何实现 M。
Repository 模式是实现 M 的持久性部分的一种方式。ActiveRecord 是另一种方式。选择哪种模式取决于应用程序的复杂性和您的偏好。

查看 NerdDinner 教程的 Step 3，他们在其中使用 Linq to SQL 创建了一个简单的存储库。
Linq to SQL 不会死。微软仍将改进核心并在有意义的地方添加客户请求，但实体框架将是主要关注点。看看这篇LINQ to SQL changes in .NET 4.0的帖子。

EF 的使用方式与 LINQ to SQL 类似，但它也更灵活，因此可以以其他方式使用。例如，EF4 将或多或少支持您自己的 POCO 对象在更领域驱动的设计中的持久性。

【讨论】：

非常丰富的答案。我应该可以给这个答案投票 3 次！

【解决方案2】：

是的，我认为 MVC 是一种不同于我认为您在这里所说的“3 层”架构（您主要创建 3 个项目 DAL、BL 和 UI 的架构）的方法。 MVC 背后的主要思想是其每个组件（模型、视图和控制器）之间的关注点分离。控制器是负责处理用户请求的组件，在大多数情况下，它与“模型”组件配合使用，以便将所需的视图显示为对用户请求的响应。这与传统的 3 层架构之间的区别在于，DAL 和 BL 现在被分组并命名为模型，是的，您仍然需要创建这些组件。
什么是存储库？
Martin Fowler 提到存储库的定义为“使用类集合接口访问域对象在域和数据映射层之间进行调解” 存储库是数据访问层的一部分，它们不要自己访问数据，它们是域和数据映射实体之间的中介，当然它们应该放在你的模型文件夹/项目中。

Linq to SQL 会被弃用吗？
NO 和同一本书中这样说，Damien Guard（ADO.NET 团队的开发人员）在他的一篇博客文章中也提到 Linq to SQL 将包含在 .NET 4.0 中。

如何与 EF 交互？
就像使用 Linq to SQL 一样。与 Linq to SQL 一样，Entity Framework 将是您的映射实体，并且也将驻留在 Model 项目中。
希望这会有所帮助！

【讨论】：

【解决方案3】：

我猜你对这些事情有点困惑，他们令人困惑，所以让我们慢慢回顾一下。

N-Tiered Architecture 和 MVC 不同，但又相互交织。 N-Tier 通常谈论分离数据访问、业务逻辑和用户界面。但是，有些人可能会争辩说，将 BLL 与 UI 完全分开是不可能的； MVC 以这样一种方式解决了这个问题，即有一个相应的 Controller 与您的 BLL 和您的 View 对话，而不是让您的 View 直接与您的 BLL 对话。
是的，拥有存储库是拥有 DAL 的一种方法。有很多方法可以做到这一点，你不应该局限于书中讨论的内容。
本书仅使用 LINQ to SQL 以最快的方式演示 ASP.NET MVC，但这不是唯一的方式。暂时停止思考 LINQ to SQL；无论您使用像 NHibernate 这样的 ORM，还是使用普通的 ADO.NET + DAL Factory 或其他任何东西，都可以使用 ASP.NET MVC——您将无法使用的是那些您拖动的 ASP.NET ObjectDataSources并与您的 UI 一起放置。

关于实体框架，Brad Abrams 在how to use Entity Framework with ASP.NET MVC 上写了一篇不错的指南，应该涵盖了您的最后一个问题。

HTH

【讨论】：

【解决方案4】：

是的，您仍然需要自己创建数据访问和业务逻辑层。有些人可能会争辩说，控制器层 IS 是业务逻辑，但我个人更喜欢将真实业务逻辑（例如定价计算）与屏幕业务逻辑（例如“确定”按钮的事件处理程序）分开。然后，您将从 Controller 类中调用它们。控制器类控制屏幕的逻辑并管理从数据/业务逻辑层到屏幕值的转换。
ASP.NET MVC 框架对“模型”层没有任何限制，这意味着您可以使用任何您想要的东西，包括 NHibernate、LINQ to SQL 或实体框架。我使用 LINQ to SQL，因为它很简单。
不确定，从未读过那本书。我刚刚从 codeplex 下载了 Scott Hanselman 的 Nerddinner 项目，并将其用作编写 ASP.NET MVC 网站的指南。

【讨论】：

在你的第二点中，这完全是关于持久层，而不是模型层，可以说可能是。
首先我称之为“模型”层，因为这个问题是关于 MVC 的。其次，就像我在第 1 点中所说的那样，我也在“模型”层处理“业务逻辑”，所以它不只是关于持久性。
它非常困惑。我的意思是我从未听说过这种分离“屏幕业务逻辑”和“真实业务逻辑”。为什么简单的说业务逻辑和表现逻辑，然后就变成了模型和视图。我也在模型中处理业务逻辑，但它如何包含持久性，这是我的观点。它作为一个单独的层，如果不是那么确实是一个不好的做法。
顺便说一句，如果您没有找到 MVC 回答的持久性，那么您会将其归因于 M。我不明白这一点。
这样说，如果你把你所有的业务逻辑都放在Model层，你怎么在另一个程序中复用呢？这是否意味着您必须在程序中添加对网站的引用才能调用该方法？没有意义吧？