Aspnetcore: MVC 太复杂而无法使用？

创建于 2019-01-26 · 26评论 · 资料来源: dotnet/aspnetcore

您的功能请求是否与问题有关？请描述。

我正在评估 MVC。问题似乎是 MVC 是复杂的火箭科学，但我一定遗漏了一些东西。请解释为什么有人会在 ASP.NET webforms 和 Entity FrameWork 的 SqlCommand 类上使用 MVC。

描述您想要的解决方案

我想轻松加入几个表并能够调试结果。但即使是一个简单的连接也是令人难以置信的复杂。

描述您考虑过的替代方案

失去火箭科学或提出无需多年学习即可理解的替代程序。或者请为我确认将 ASP.NET 网络表单与 Entity FrameWork 的 SqlCommand 类一起使用确实是一种更简单的方法。

我附上了来自 Contoso University MVC 示例的两个屏幕截图。请解释任何人应该如何理解正在发生的事情？我什至无法在 Watch 窗口中查看结果集。生成的查询 - 也附加了 - ...天哪，你在开玩笑吗？对于什么应该是一个简单的连接？如果我必须调试它怎么办？

除了在 Visual Studio 前度过了一年的隐修生活，弄清楚了构建网站的声明式设计方法之外，我在这次评估中还缺少什么？

非常感谢清晰简洁的回复。

谢谢你。

screen shot 2019-01-26 at 1 24 01 pm

附加上下文

在此处添加有关功能请求的任何其他上下文或屏幕截图。

area-mvc

资料来源

LJ9999

👎37 😕17 🚀11 😄11 👍3 👀2

最有用的评论

如果您不喜欢 EntityFramework 等 ORM（对象关系映射器），您可以使用 ADO.NET 手动编写 SQL。您还可以使用不生成查询的轻量级 ORM，例如Dapper （您可以手动编写它们）。 EntityFramework 还具有 ExecuteSQL 方法，可在必要时为您提供更多控制（https://docs.microsoft.com/en-us/ef/core/querying/raw-sql）。

davidfowl 于 2019-01-26

👍49 ❤5

所有26条评论

davidfowl 于 2019-01-26

👍49 ❤5

此外，如果 MVC 对于简单页面来说看起来过于复杂，请尝试使用Razor Pages

davidfowl 于 2019-01-26

👍31 ❤3

我强烈建议您遵循众多 MVC 教程之一；一个人不能指望仅仅从 5 分钟看新的项目模板就可以理解一些东西。

至于相对于 webforms 的简单性，我是否可以提醒您 viewstate 的不幸，runat=server 和上帝将我们从页面生命周期中拯救出来。
亲切的问候

borland 于 2019-01-27

👍31

这很好笑。

jakenuts 于 2019-01-27

😄6

对我来说似乎很简单。

ciel 于 2019-01-27

👍5

此外，如果 MVC 对于简单页面来说看起来过于复杂，请尝试使用Razor Pages

刚刚完成了一个 WebForms -> RazorPages 迁移项目 - 老实说，这可能只是简单的 MVC，但对于小型“以页面为中心”的网站来说绝对是一个不错的选择。在 MVC 项目中，我发现我“寻找”代码太多了，即。不断地从视图跳到控制器，滚动浏览大量的动作，而在 RazorPages 中我只是直接进入 PageModels。

我讨厌臃肿的 EF - Dapper 要简单得多，尤其是与Dapper.FastCRUD 之类的东西一起使用时

mrwoodo 于 2019-01-27

👍2

@LJ9999不仅仅是你，MVC 和任何框架都没有所有的答案。它可能不是最适合您的项目的结构，也可能不适合您的想法。除非您喜欢自我惩罚，否则无需尝试将方钉插入圆孔中。

MVC 是您的选择之一。评估几种不同的方法，然后选择最适合您的方法。找到对你有意义的东西。找到（或制作）你最有效率的东西。不要被流行的东西所左右。受欢迎并不总是与优点有关，即使一个案例的优点在其他地方也不起作用。

因此，让我和你一起对最常见的事情完成方式持怀疑态度。对每个人采取的方法持怀疑态度，批判性地思考和为自己思考是一个很好的起点。如果你认为你可以做得更好，你可能可以。去吧！

对于任何认为这是对他们和他们选择的流行方式的攻击的人来说，这真的不是对你的攻击。它是说找到对你有用的东西。所以这只是一个关于计算机如何运行在同一种语言上的声明，而人们的思想却不是。每个人都不一样，这很好。

c9fe 于 2019-01-27

👍2 ❤1

+1 小巧玲珑，使用它。

至于为什么使用实体框架，它是一种快速简便的方法，可以用您定义代码的相同语言表达您想要的行为，并支持代码生成（阅读：缩短上市时间）。不过，我通常不使用它，您也不必这样做。

在一个例子中，您似乎更关心它的用法。答案是目标受众：2019 年，精通 ORM 范式的人比真正精通 SQL 的人多。 SQL 并没有死，它只是在年轻的开发者队伍中有很多激烈的竞争和高渗透率。

AsParallel 于 2019-01-27

作为一个经历过 Asp.Net 和 MVC 的每一次迭代的人，以及我们现在使用 Asp.Net Core 所拥有的东西，我可以告诉你，调试页面生命周期错误并尝试使用 web 表单创建任何相对复杂的东西是一场噩梦。到 MVC。 WebForms 隐藏了许多看似神奇的事件背后正在进行的实际工作。它通过尝试握住您的手并假装 Web 不是无状态的来抽象 Web 请求的整个工作方式。它对你撒谎，告诉你你很漂亮，而且你的屁股穿牛仔裤很好看。它错误地建立了您的信心并使网络技术变得模糊。你幸福地继续你的一天，认为如果你可以制作一个带有表格的网页并将其保存到表格中，那么你可以做任何事情。直到您获得构建自定义动态表单的新要求。或者用这个特定的客户端框架做一些事情，因为客户认为它很漂亮。你意识到你现在正在逆流而上，并想知道其他人是如何做到的。
MVC 不是火箭科学，它是一种经过验证的模式，在意识到“必须有更好的方法”和多年来在方孔中钉住圆钉之后在开发社区中发展起来。如果你认为它很复杂，那可能是因为你没有遇到任何它应该解决的问题，而且你没有花足够的时间解决复杂的问题。如果这个教程太难了，请从更简单的教程开始。
如果您认为这不适合您，那么总会有 PHP 或 NodeJs。

falvarez1 于 2019-01-27

👍14 😄3

对于不只是简单连接的事情，我只会使用 EF 的 ExecuteSQL。我确实认为您可能低估了它可能试图表示的复杂性，因为它没有办法在逻辑上命名连接表，并且它可能需要灵活地处理办公室分配。如果您不喜欢 EF，那么您并不孤单。大多数使用 MVC 的人可能没有使用 EF。一个不需要另一个。

就我个人而言，我发现 webforms 比 MVC 复杂得多，因为它们有太多复杂的事件逻辑，掩盖了实际的请求响应周期。 MVC 对于从未想过的人来说一开始很难，因为它是一种不同的组织模型，但经过多年的使用，业界似乎已经决定，从长远来看，MVC 实际上更简单。这只是一个偏好问题，但在多年来一直是主流的技术上开这样的票只是发泄。

我建议使用不使用实体框架的示例来学习 MVC，以便您一次学习一个概念。然而，这并不是真正适合谈论它的地方。

PaluMacil 于 2019-01-27

👍2

天哪，我现在笑得很厉害。

伙计，如果它看起来太难或太复杂，那么请远离它并使用其他东西。没有人拿枪指着你的头，对吧？

我们中的一些人已经在这个街区转了几次，并且更喜欢简单的 asp mvc 而不是 web 表单，因为我们不得不处理来自单体 web 表单怪物的大量不可测试的意大利面条代码。

但说真的，如果你喜欢 Web 表单，并且有人愿意付钱给你编写 Web 表单代码，那就去做吧！并且停止抱怨你不理解的东西。

camainc 于 2019-01-27

👍8

这是一篇讽刺文吗？不知道是在reddit还是github...

rhythmnewt 于 2019-01-27

😄9

我曾在 Asp.net Web 表单和 Asp.net MVC 下为两个不同的系统进行 ERP 开发，我可以自信地说，在 Web 表单上工作是一种折磨，尤其是当你有一个架构很差的庞大解决方案时，反之亦然MVC 可以神奇地将丑陋的架构转变为具有组织层的能力的顶级解决方案，并利用具有强大可靠 ORM（如 EF）的存储库模式。
但老实说，我遇到的大多数抱怨 MVC 的开发人员都受苦于对新模式的经验和知识有限。
我个人建议想要从零到英雄学习 MVC 的开发人员尝试https://www.pluralsight.com而不是浏览网络并在 MVC 上的有争议的主题和博客上浪费时间和金钱，这些主题和博客在许多情况下是有偏见的或糟糕的在上下文中。

AshrafSada 于 2019-01-27

👍1

哇，那个时代有变化的开发者是真的。当我在 2013 年第一次遇到 EF 和 MVC 时，我称赞 Microsoft 是多么简单和直接。就像已经说过的那样，理解这些框架不会自动发生！按照教程，观看数百个视频中的几个，然后重试。对不起，伙计，但是当您花时间处理这些事情时，您就会对这些事情有所了解

joeizang 于 2019-01-27

👍2

我同意作者的观点。对于那些第一次使用 mvc 的人。该方法不如 php、rail 等其他方法友好。在使用之前需要理解太多概念。但是，一旦你有了这个概念，mvc 似乎就非常有效了。

hanoitown 于 2019-01-27

为什么会有人讨厌实体框架。在过去三年中，我不得不编写不超过 5 个 SQL 查询。

kwakuduahc1 于 2019-01-27

虽然这不是火箭科学，但最后它背后有一些科学，就像所有事情一样，可能需要一些时间和精力才能完全理解，我和原作者一起，MVC 和样本有点当试图一次理解所有内容时，如果在应用来自其他框架的知识或概念时使用某种备忘单可能会使学习 MVC 对那些发现它具有挑战性的人来说更容易忍受。

虽然反馈总是很受欢迎，因为如果有人抱怨，这意味着有一些需要改进的地方，另一方面，如果你对作者的帖子进行一点调查，你会发现他非常直言不讳，并且比较了很多东西火箭科学。

REscobar 于 2019-01-27

🚀2 👍2 🎉1

即使事情不是火箭科学，它们仍然可能很复杂，需要耐心研究。阅读更多关于该主题而不是抱怨它太难可能是一个不错的起点。

mcqueene 于 2019-01-27

😕1

看来您的问题不在于 MVC，而在于实体框架。对于我们中的一些人来说，编写 SQL 很舒服，实体框架添加了一个不受欢迎的抽象层。就个人而言，我使用 Dapper，这使得使用 Readers 变得更加容易。您仍然可以编写自己的 SQL。 MVC 是一个非常简单的模式。理解如何传入和传出数据以及如何有效地使用一些辅助函数变得有点棘手，但从概念上讲并不难。

MVC 不需要使用 EF，尽管内置的用户身份验证使用它。

masilver99 于 2019-01-27

朋友们，用帮助或积极的态度发表评论，但不要嘲笑。 OP 似乎确实对 EF 有疑虑，David 的评论非常好。 https://github.com/aspnet/AspNetCore/issues/7039#issuecomment -457869924

问题是一个帮助的地方。如果您想争论 MVC 与其他东西的优点，请尝试 Internet 上其他流行的投诉网站之一。

shanselman 于 2019-01-27

👍10 ❤3

嘿欢迎@LJ9999我希望更多的人会问这样的问题。
我首先要说这只是我的意见，所以请随意同意或不同意其中的任何或全部。

我完全同意网络/软件开发很难。我个人花了数年时间学习和试验，以获得我所拥有的经验。任何时候我想使用一个新的框架或库仍然很难。它需要我花更多的时间再次学习和尝试才能舒适和自信地使用它。随着这些年来我学到的越来越多，我真的相信我在学习方面变得更好更快，因此变得更容易。
多年来，我认为所涉及的挑战已经改变。有些事情变得更容易了，但也引入了新的挑战。但总的来说，我相信现在与我开始时相比要容易得多。我也认为它不那么令人沮丧，而且我发现它更令人愉快。
说了这么多，我认为作为一个行业，我们总是可以继续争取更好。我认为这样的问题突出了我们面临的挑战，并激发了继续改善局势的必要性。

我要特别小心，不要建议您选择一种解决方案而不是另一种，因为我认为没有足够的信息让我这样做。
我发现解决问题的最大挑战之一是确定正在解决的实际问题。很容易将此问题归类为需要“建立网站”，但是有这么多解决方案可供选择来“建立网站”，其中任何一个都可能起作用。问题需要尽可能地分解，因为这提供了评估不同解决方案的标准。
其次，我们都有个人喜好。您有权拥有自己的权利，没有人能告诉您您更喜欢什么或使用什么感觉更舒服。这完全取决于你。
此外，当涉及其他人（团队或公司）时，可能需要考虑其他因素，例如团队的偏好以及公司的政策和战略。
这些只是评估不同解决方案时需要考虑的一些因素。

我想解决的最后一件事是您的信息。我认为它不够具体，无法理解您对回复的期望。在我的解释中，有许多不同的问题，您试图得到答案，并提供您的意见。这些都是有效且有用的，但是当在一个 github 问题中一起提出和提出时，很难整理出清晰简洁的答案或开始讨论以提供您寻求的答案。
我对您的建议是再试一次，并更具体地提出您的问题或意见。不要担心打开很多问题，如果它们写得很好并且范围很广，它们会更容易被接受，并且你更有可能得到问题的答案或得到适当的指导。

我希望这个回应在某种程度上有所帮助。只要知道有很多人愿意提供帮助，但是您有责任让他人轻松帮助您。

VishalMadhvani 于 2019-01-27

@LJ9999一个（希望是建设性的）评论...

从您发布的 SQL 来看，您可能正在使用 Entity Framework 6。Entity Framework Core（从头开始编写的较新版本）的明确目标是生成健全、可读的 SQL，该 SQL 试图类似于您自己编写的内容 -如果您尝试一下，很有可能会看到更合理的结果 - 试一试并告诉我们。

roji 于 2019-01-27

我的底线标准很简单......要实现的代码行数。更多代码 - 更多错误风险、更大的学习曲线、更多浪费的时间（除非您是按小时计费的承包商）。
我已经看到使用 Javascript 框架执行 mvc 的代码量增加了 8 倍。在老式的 cshtml 页面上。而且时间增加了 5 倍。

当心那些使用“正确方式”的人

kenlassesen 于 2019-01-27

在这种情况下，MVC 作为一种软件架构对你更有帮助。
M 是模型，它可以是你的数据库，它可以响应信息请求，响应指令以改变其信息的状态，甚至在信息发生变化时通知事件驱动系统中的观察者。
V 是视图，它有效地提供了应用程序的用户界面元素。它将模型中的数据呈现为适合用户界面的形式。
C 是控制器，它接收用户输入并调用模型对象或仅渲染视图。

您选择的技术堆栈并不意味着 MVC 的好坏，它只是一种软件架构。

revskill10 于 2019-01-27

@shanselman

朋友们，用帮助或积极的态度发表评论，但不要嘲笑。 OP 似乎确实对 EF 有疑虑，David 的评论非常好。第7039章（评论）

我完全同意斯科特。

同样可以理解的是，一些更有经验的用户强烈认为一个标题似乎会在一个声明中将一个伟大的框架和 ASP.NET 核心团队和社区多年的辛勤工作视为“不可用”，即使那是大概不是本意。我想这可能引起了嘲笑。

更改标题以匹配实际问题可能会有所帮助。

mharthoorn 于 2019-01-28

我们会定期关闭长时间未更新的“讨论”问题。

如果这造成任何不便，我们深表歉意。我们要求，如果您仍然遇到问题，请使用更新的信息记录新问题，我们将进行调查。

aspnet-hello 于 2019-04-19

此页面是否有帮助？

0 / 5 - 0 等级

Aspnetcore: MVC 太复杂而无法使用？

您的功能请求是否与问题有关？ 请描述。

描述您想要的解决方案

描述您考虑过的替代方案

附加上下文

最有用的评论

所有26条评论

相关问题

您的功能请求是否与问题有关？请描述。