【问题标题】:Reasons not to use MVC architecture for web applicationWeb 应用程序不使用 MVC 架构的原因
【发布时间】:2011-02-23 02:07:33
【问题描述】:

过去,我主要使用 N 层架构构建所有 Web 应用程序,实现 BLL 和 DAL 层。最近,我开始做一些 RoR 开发以及研究 ASP.NET MVC。

我了解不同架构之间的差异(正如其他一些 SO 帖子所引用的那样),但我真的想不出为什么我不会为新项目选择 MVC 模型。

在您的经验中,您是否有任何原因/时间不适合 MVC 架构,或者您选择 BLL/DAL 架构的任何原因?

【问题讨论】:

  • 这是关于 .NET 的 MVC 还是一般的 MVC?后者我知道一点,但对前者一无所知。
  • 确实,这个问题更多的是关于 Web 应用程序的 MVC 架构,尽管我很高兴听到对特定实现的任何回应。
  • 我将其解读为“不将 MVC 架构用于 Web 应用程序的 100 个理由”

标签: model-view-controller n-tier-architecture


【解决方案1】:
【解决方案2】:

对于某些页面,MVC 可能有点矫枉过正:

  • 启动页面
  • 目标网页
  • 一次使用后将被丢弃的营销页面
  • 一次性的

创建一个漂亮的 MVC 架构很容易,当一个小页面,简明扼要地写在这些情况下就可以了。

如果您遇到时间问题,并且您需要非常快地完成某些事情,MVC 也可能不切实际。就像您的营销团队正在参加会议一样,他们遇到了麻烦,需要在他们失去最大客户之前的那一刻在他们的展位上展示一些东西。

【讨论】:

    【解决方案3】:

    就个人而言,我会根据目标应用程序的复杂性对其进行评分。 MVC(或更一般的结构化方法)非常适合大规模应用程序,在这些应用程序中,设计一致性和代码隔离的好处超过了支持设计的成本。

    如果网站很小,或者页面/控件很少,我会避免坚持严格的设计模式。但这只是我的偏好。

    正如一位发帖人所说,您还必须考虑任何现有应用程序的状态,以及您的开发团队技能/经验。

    【讨论】:

      【解决方案4】:

      其中一个因素可能是您的网络应用程序的状态。如果它是一个基本的 Web 应用程序,它通过一些 JavaScript 钩子(例如客户端验证)从服务器获取所有内容,那么 Rails 类型的 MVC 真的很棒。我不熟悉 ASP.NET 上的 MVC,但我听说它与 Rails 中的类似。

      如果 Web 应用程序确实是有状态的,那么更好的方法是使用双 MVC 层——一个在客户端,另一个在服务器端。服务器上的 MVC 将主要关注身份验证、授权、以标准格式生成数据等。客户端 MVC 将关注诸如 DOM 事件、用户操作、它们如何影响应用程序状态以及如何/何时应向服务器请求/发送数据。

      MVC 只是一种组织代码的方式,就像 BLL 或 DAL 一样。 Rails 中的 MVC 基本上通过使用一组约定完全隐藏了 DAL。通常业务逻辑驻留在模型本身中。但是,如果您的应用程序需要更复杂的 BLL,其中对象交互可能很复杂,那么 BLL 没有理由不能与 MVC 中的 M 和平共存。

      【讨论】:

        【解决方案5】:

        简单的答案是,不。

        MVC 的架构比老式的 n 层架构更好,原因有很多。这是其他 UI 模型(例如 Swing)中的标准方法。开发 Web 应用程序需要这么长时间的唯一原因是,软件社区集体花了一点时间来适应 Web 的无状态,并能够以一种方式处理视图和控制器:有道理。

        【讨论】:

          【解决方案6】:

          Life above the service tier 建议您应该以符​​合 SOFEA 原则的方式使用 MVC 模式,并注意伪装在 MVC 首字母缩写词后面的“前端控制器”类型框架。 (或者,您仍然可以使用它们,但至少阅读文章,了解差异并明智地选择)。

          【讨论】:

            【解决方案7】:

            仅当我有一个使用 MVP 构建的现有桌面应用程序并且我必须将其转换为 Web 环境时,我才不会使用 MVC 模式。那是因为我已经为演示者编写了逻辑。
            在任何其他情况下,我都会使用 MVC。

            【讨论】:

              【解决方案8】:

              我们唯一的缺点是 MVC 将您推向 html/javascript 界面,富互联网应用程序变得更加困难。例如,如果您想向用户展示一个日历控件,您可能需要自己滚动,因为您无法从工具箱中拖放一个。也就是说,MVC 很棒。当我们真正需要 RIA 应用程序时,我们会使用 MVVM 和 Silverlight。

              【讨论】:

              • 这完全取决于您的工具。 MVC 是一个通用术语,而不是特定于 .NET 的术语。
              【解决方案9】:

              我们已经为Windows应用程序使用了MVC,现在我们需要在Web应用程序中转换那个东西我们没有任何问题。我们正在使用 Web 服务,每个业务逻辑都在 Web 服务中。 因此,您可以在 Web 应用程序中使用 MVC。 M-Model(与业务逻辑通信的函数和过程) V-View(设计) C-Controller(表单逻辑) 所以这在 DAL、BLL 和 MVC 中没有任何联系。 您可以定义您的业务逻辑并在 MVC 中的任何位置使用它。 这就是我的观点 MVC 对于可重用性非常有用,如果您的应用程序很大,那么您必须使用 MVC。

              【讨论】:

                【解决方案10】:

                我不会只在由 ~1-2 个文件和 ~10-20 行代码组成的非常小的项目中使用 MVC。而且它们几乎不会演变成更大的东西。

                但如果他们愿意,是时候将它们重新架构成 MVC 了。

                【讨论】:

                  【解决方案11】:

                  为了我?我不使用 MVC 的唯一原因是因为我正在处理的应用程序已经在 Web 表单中启动。我不是废弃/重写的大支持者,但我所做的任何新事物都在 MVC 中。

                  【讨论】:

                    【解决方案12】:

                    我不认为您的选择是相互排斥的。在将 BLL/DAL 用于模型逻辑时,您可以完美地使用 MVC。

                    您可以根据自己的喜好实现 MVC 的 M 部分,对此没有任何限制。使用 BLL 和 DAL 将是一个有效的选择。

                    【讨论】:

                    • 我明白你在说什么,但我真的想我想找出我不想使用 MVC 模型期间的原因?例如,我必须使用 BLL/DAL 在 ASP.NET MVC Web 应用程序上创建一个 ASP.NET Web 应用程序的原因是什么?我问的原因是 MVC 设置似乎可以节省重复任务的时间和精力(无论平台如何),所以我试图看看是否还有其他因素我应该考虑。
                    • 克劳迪奥仍然是正确的。 MVC 中的模型只是使您能够以可重用的方式抽象和管理数据。它可能隐藏了数据库、Web 服务或整个 n 层系统; MVC 仍然有效,因为它仅指您的 Web 应用程序,而不是整个企业。
                    • 这个答案+1。 N-Tier 是一种架构,而 MVC 是一种设计模式 - 您可以同时使用这两种模式,而且没有真正的理由不在网页上使用 MVC,因此寻找不使用它的理由是徒劳的。
                    猜你喜欢
                    • 2014-10-26
                    • 2015-08-18
                    • 2016-05-28
                    • 2011-12-06
                    • 1970-01-01
                    • 2011-02-02
                    • 2012-08-25
                    • 1970-01-01
                    • 1970-01-01
                    相关资源
                    最近更新 更多