问题 我需要对MVC架构和三层架构进行一些澄清


我一直在阅读Pro ASP .NET MVC框架书,我对很多事情感到很困惑。我一直在努力做一些研究,但我发现有这么多不同的方法和概念被抛向我,这只是让事情变得更糟。
所以我有几个问题:

  1. 我知道MVC应该将功能分为三个主要部分:模型 - >控制器 - >视图。 MVC与三层架构不同吗?或者我仍然应该考虑在我的项目中创建数据访问层和业务逻辑层?

  2. 什么是存储库?它是什么作为我的数据访问层?存储库在哪里/如何适合MVC?

  3. 本书讨论了如何使用LINQ to SQL与数据库进行交互,但它指出将来不支持LINQ to SQL,并且Microsoft正在为实体框架删除它。实体框架在哪里适合MVC以及如何与它进行交互?

在此先感谢您的帮助!
马特


11383
2018-06-22 04:15


起源

LINQ to SQL是〜不被删除,它在你的Pg书中说明了很多。 49。 - mmcdole
另外,就MVC和Three-Tier之间的差异而言,我建议你重新阅读pg。 41特别是顶部的最后一段。 - mmcdole
我确实看到它将被包含在ASP.NET 4.0中,但我认为它仍在慢慢被删除。好的,是的,我确实读过那段。就像我说的那样,所有的条款和概念立刻被抛到了我身上,我有点困惑,忘了我读过的一些东西。谢谢。 - Matt
@Matt,我会说这不是真正的初学者在该领域的最佳书籍。并不是说它不是一本好书,我真的很喜欢它。但是“Pro ASP.NET MVC”就是这本书,更适合退伍军人。如果我过去没有多次介绍这些概念,我想我也会感到困惑。 - mmcdole
@Matt,LINQ在这里与我们待了很长时间。实体很好,但不像大多数人不会使用LINQ to Entities,所以学习和使用LINQ根本不是一个糟糕的选择。 - mmcdole


答案:


  1. MVC主要是表示层的模式,它侧重于视图和控制器之间的交互。该模型可以被认为是 应用程序的组件,负责维护状态,包括持久性。

    在一个简单的应用程序中,该模型可能只是一个LINQ-To-SQL模型。在大型企业应用程序中,模型可能包含数据访问层,业务层和域层。 ASP.NET MVC并不限制您应该如何实现M.

  2. 知识库 模式是实现M的持久性部分的一种方式 ActiveRecord的 是另一个。选择哪种模式取决于应用程序的复杂程度和您的偏好。

    看一眼 第3步 NerdDinner教程,他们使用Linq to SQL创建一个简单的存储库。

  3. Linq to SQL不会死。微软仍将改进核心并在有意义的地方添加客户请求,但实体框架将成为主要关注点。看一下这篇文章吧 .NET 4.0中的LINQ to SQL更改

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


7
2018-06-22 07:33



非常丰富的答案。我应该能够将这个答案投票3次! - Martin


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

Linq to SQL会被弃用吗?
没有 同样的书也是这样说的,Damien Guard(ADO.NET团队的开发人员)在他的一篇博客文章中提到Linq to SQL将包含在.NET 4.0中。

如何与EF互动?
就像你使用Linq to SQL一样。与Linq to SQL一样,Entity Framework将成为您的映射实体,并且也将驻留在Model项目中。
 希望这可以帮助!


6
2018-06-22 05:54





我猜你对这些事情有点困惑,他们  让人感到困惑,让我们慢慢来看看。

  1. N层架构和MVC是不同的,但交织在一起。 N-Tier通常谈论分离数据访问,业务逻辑和用户界面。但是,有些人可能会认为不可能将BLL与UI完全分开; MVC解决了这种问题,即有一个相应的Controller与你的BLL和你的View对话,而不是让你的View直接与你的BLL对话。

  2. 是的,拥有存储库是获得DAL的一种方法。有很多方法可以做到这一点,你不应该局限于书中讨论的内容。

  3. 本书仅使用LINQ to SQL以尽可能快的方式演示ASP.NET MVC,但这不是唯一的方法。 停止考虑LINQ to SQL一分钟;无论你使用像NHibernate这样的ORM,还是使用普通的ADO.NET + DAL Factory或其他什么,你都可以使用ASP.NET MVC - 那些你将无法使用的是那些ASP.NET ObjectDataSources 您可以使用UI拖放。

至于实体框架,布拉德艾布拉姆斯写了一篇很好的指南 如何在ASP.NET MVC中使用Entity Framework,这应该涵盖你的最后一个问题。

HTH


1
2018-06-22 07:57





  1. 是的,您仍然需要自己创建数据访问和业务逻辑层。有些人可能会争辩说Controller层 IS 业务逻辑但我个人更喜欢实际业务逻辑(例如定价计算)与屏幕业务逻辑(例如“OK”按钮的事件处理程序)之间的分离。然后,您将从Controller类中调用它们。控制器类控制屏幕的逻辑,并管理从数据/业务逻辑层到屏幕值的转换。

  2. ASP.NET MVC框架对“模型”层没有任何限制,这意味着您可以使用任何您想要的东西,包括NHibernate,LINQ to SQL或实体框架。我使用LINQ to SQL因为它很简单。

  3. 不确定,从不读那本书。我刚从codeplex下载了Scott Hanselman的Nerddinner项目,并将其作为编写ASP.NET MVC网站的指南。


-1
2018-06-22 04:30



它的所有关于第二点的持久层,而不是模型层,可能是。 - Adeel Ansari
首先,我称之为“模型”层,因为这个问题是关于MVC的。其次,就像我在第1点中所说的那样,我在“模型”层中处理“业务逻辑”也是如此 不 只是持久性。 - oscarkuo
它非常困惑。我的意思是我从来没有听说过这种分离“屏幕业务逻辑”和“真正的业务逻辑”。为什么简单地说业务逻辑和表示逻辑,然后它将成为模型和视图。我也在模型中处理业务逻辑,但它如何包含持久性,这是我的观点。它作为一个单独的层,如果不是,那么确实是一个坏的做法。 - Adeel Ansari
顺便说一句,如果你没有找到MVC回答的持久性,那么你将把它归结为M.我不明白这一点。 - Adeel Ansari
换句话说,如果将所有业务逻辑放在模型层中,如何在其他程序中重用它?这是否意味着您必须从程序中添加对网站的引用,以便您可以调用该方法?它没有意义吗? - oscarkuo