Web 应用程序不使用 MVC 架构的原因
过去，我主要使用 N 层架构构建所有 Web 应用程序，实现 BLL 和 DAL 层。最近，我开始进行一些 RoR 开发以及研究 ASP.NET MVC。
我理解不同架构之间的差异（正如其他一些 SO 帖子所引用的），但我真的想不出为什么我不会为新项目选择 MVC 模型的任何原因。
根据您的经验，是否存在 MVC 架构不适合的任何原因/时间，或者您选择 BLL/DAL 架构的原因？
In the past I have primarily built all my web applications using an N-tier architecture, implementing the BLL and DAL layers. Recently, I have started doing some RoR development as well as looking into ASP.NET MVC.
I understand the differences between the different architectures(as referenced by some other SO posts), but I can't really think of any reasons why I wouldn't choose an MVC model going forward for a new project.
Is there any reasons/times in your experience when an MVC architecture would not be suitable, or any reasons why you would choose a BLL/DAL architecture instead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我不认为您的选择是相互排斥的。您可以完美地使用 MVC，同时使用 BLL/DAL 作为模型逻辑。
您可以根据需要实现 MVC 的
M部分，对此没有任何限制。使用 BLL 和 DAL 将是一个有效的选择。I don't think your options are mutually exclusive. You could perfectly use MVC while using BLL/DAL for your model logic.
You can implement the
Mpart of MVC as you prefer, there is no restriction about that. Using BLL and DAL would be a valid option.为我？我不使用 MVC 的唯一原因是我正在开发的应用程序已经在 Web 表单中启动。我不是报废/重写的大力支持者，但我所做的任何新事情都是在 MVC 中进行的。
For me? the only reason I'd not use MVC is because the application I'm working on was already started in web forms. I'm not a big proponent of scrap/rewrite, but anything new I do is in MVC.
因素之一可能是 Web 应用程序的状态性。如果它是一个基本的 Web 应用程序，通过一些 JavaScript 挂钩（例如客户端验证）从服务器获取所有内容，那么 Rails 类型 MVC 真的很棒。我不熟悉 ASP.NET 上的 MVC，但我听说它与 Rails 中的类似。
如果 Web 应用程序确实是有状态的，那么更好的方法是拥有双 MVC 层 - 一个位于客户端，另一个用于服务器。服务器上的 MVC 主要关注身份验证、授权、以标准格式生成数据等。客户端 MVC 将关注 DOM 事件、用户操作、它们如何影响应用程序状态以及如何/何时应请求/发送数据到服务器。
MVC 只是组织代码的一种方式，就像 BLL 或 DAL 所做的那样。 Rails 中的 MVC 基本上通过使用一组约定完全隐藏了 DAL。通常业务逻辑驻留在模型本身中。但是，如果您的应用程序需要更复杂的 BLL，其中对象交互可能很复杂，那么 BLL 没有理由不能与 MVC 中的 M 和平共存。
One of the factors could be the statefulness of your web application. If it's a basic web application that gets everything from the server with a few JavaScript hooks such as client side validations, then the Rails type MVC is really great. I am not familiar with MVC on ASP.NET, but I've heard it's similar to that in Rails.
If the web application is really stateful, then a better approach would be to have a dual MVC layer - one on the client side, and the other for the server. The MVC on the server will mostly concern itself with authentication, authorization, churning out data in standard formats, etc. The client side MVC will concern itself with things such as DOM events, user actions, how they affect the application state, and how/when should data be requested/sent to the server.
MVC is just a way to organize code, just as BLL or DAL would do. MVC in Rails basically hides DAL altogether by using a set of conventions. Usually business logic resides in the models itself. However, if your application demands more complex BLL where object interactions can be intricate, then there's no reason why that BLL can't peacefully co-exist with the M in MVC.
我不仅仅在由 ~1-2 个文件和 ~10-20 行代码组成的非常小的项目上使用 MVC。而且它们很难演变成更大的东西。
但如果他们愿意，那么就该将它们重新架构为 MVC 架构了。
I don't use MVC only on really tiny projects consisting of ~1-2 files and ~10-20 lines of code. And they will hardly evolve into something bigger.
But if they will, it will be time to rearchitect them into a MVC ones.
我们遇到的唯一缺点是 MVC 将您推向 html/javascript 界面，在这种界面中，丰富的互联网应用程序变得更加困难。例如，如果您想向用户展示日历控件，您可能需要推出自己的日历控件，因为您无法从工具箱中删除一个控件。也就是说，MVC 很棒。当我们真正需要 RIA 应用程序时，我们使用 MVVM 和 Silverlight。
The only drawback we've had is that MVC pushes you toward a html/javascript interface where rich internet applications become more difficult. For example if you want to present the user with a calendar control, you may need to roll your own since you can't drop one on from the toolbox. That said, MVC is great. When we really need RIA applications we use MVVM and Silverlight.
对于某些页面，MVC 可能有点矫枉过正：
、营销页面，这些页面 。在这些情况下都可以。
如果您遇到时间问题并且需要非常快地完成某些任务，那么 MVC 也可能不切实际。就像您的营销团队外出参加会议一样，他们遇到了麻烦，需要在失去最大客户之前在展位上展示一些东西。
For certain pages, MVC can be a little overkill:
It's easy to get wrapped up creating a beautiful MVC architecture, when a small page, concisely written, can be OK on these situations.
MVC may also be impractical if you're in time trouble, and you need something out REALLY fast. Like your marketing team is out at a conference, they're having trouble, and needs something to show in their booth this second before they lose their biggest customer.
服务层之上的生活建议您应该使用MVC 模式遵循 SOFEA 原则，并注意隐藏在 MVC 缩写后面的“前端控制器”类型框架。
（或者，您仍然可以使用它们，但至少阅读文章，了解差异并明智地选择）。
Life above the service tier suggests you should use the MVC pattern in a way that adheres to the SOFEA principles, and watch out for "Front controller" type frameworks disguising behind the MVC acronym.
(or, you can still use them, but at least read the article, understand the differences and choose wisely).
简单的答案是，不。
出于多种原因，MVC 是一种比老式 n 层架构更好的架构。这是其他 UI 模型（例如 Swing）中的标准方法。花了这么长时间才进入 Web 应用程序的唯一原因是，软件社区集体花了一些时间来适应 Web 的无状态性，并能够以一种以下方式处理视图和控制器：有道理。
The simple answer is, no.
MVC is all around a better architecture than your old-school n-tier architecture, for many reasons. It's the standard approach in other UI models (e.g. Swing). The only reason it took so long to make it to web applications was because it took the software community, collectively, a little while to get used to the statelessness of the web and to be able to deal with the views and controllers in a way that made sense.
就我个人而言，我会根据目标应用程序的复杂性对其进行评分。 MVC（或者一般来说更结构化的方法）非常适合大规模应用程序，在这些应用程序中，设计一致性和代码隔离的好处超过了支持设计的成本。
如果它是一个小网站，或者很少的页面/控件，我会避免坚持严格的设计模式。但这只是我的偏好。
正如一位发帖者所说，您还必须考虑任何现有应用程序的状态以及您的开发团队的技能/经验。
Personally, I would rate it based on the complexity of the target application. MVC (or more structured approaches in general) lend themselves very well to large scale applications where design consistency and segregation of code is a benefit outweighing the cost of supporting the design.
If its a small site, or very few pages/controls, I would avoid sticking to strict design patterns. But that is just my preference.
As one poster said, you also have to consider the state of any existing applications, and your development team skills / experience.
我们已经在Windows应用程序中使用了MVC，现在我们需要在Web应用程序中转换那个东西，我们在任何事情上都没有任何问题。我们正在使用 Web 服务，每个业务逻辑都在 Web 服务中。
这样您就可以在 Web 应用程序中使用 MVC。
M-模型（与业务逻辑通信的函数和过程）
V型视图（设计）
C-控制器（形式逻辑）
所以 DAL、BLL 和 MVC 中没有连接。
您可以定义业务逻辑并在 MVC 中的任何位置使用它。
这是我的观点，MVC 对于可重用性非常有用，我更喜欢如果您的应用程序很大，那么您必须使用 MVC。
We have already use the MVC for the Windows application,Now we need to convert that thing in the Web application we don't have any problem in any thing. We are using the Web service and every Business Logic is in the Web service.
So you can use the MVC in the web application.
M-Model(Functions and Procedure which communicate with Business logic)
V-View(Design)
C-Controller(Form Logic)
so that is no connection in the DAL,BLL and in MVC.
you can define your Business logic and use in it any where in the MVC.
That's my point of view MVC is very useful for Re-usability i prefer if your application is big then you must use MVC.
仅当我有一个使用 MVP 构建的现有桌面应用程序并且必须将其转换为 Web 环境时，我才不会使用 MVC 模式。那是因为我已经为演示者编写了逻辑。
在任何其他情况下我都会使用 MVC。
I wouldn't use MVC pattern only in the case when I have an existing desktop application built with MVP and I have to convert it to a web environment. That's because I already have written logic for presenter.
In any other case I would use MVC.
您可以参考以下
http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should- i-use-it.aspx
和 http://msdn .microsoft.com/en-us/magazine/dd942833.aspx#id0080017 请参阅“无可争议的事实”。
You can refer to following
http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should-i-use-it.aspx
and http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080017 refer "Undisputable Facts".