分层 Web 表单归类为 MVC？
在我工作的地方，我们有一个项目，是用 .NET3.5 编写的 Webforms 项目。它是分层的；表示层、逻辑层、数据层。
我们每周都会举行“技术会议”。我做了一个关于 MVC 的演讲。
我的技术主管决定插话，并告诉我上面的项目（分层、Webforms）与 MVC 相同。他接着描述了以下内容：
- 视图只是 ASPX 页面
- 控制器只是页面后面
- 模型只是数据对象
长话短说 - 我们就上述项目（分层 Web 表单）是否构成 MVC 展开了一场悬而未决的争论。
有人可以提供并回答这场辩论吗？
谢谢
Where I work, we have a project, written in .NET3.5 as a webforms project. It is tiered; presentation layer, logic layer, and data later.
We have these weekly 'tech sessions' at work. I gave a presentation about MVC.
My tech lead decided to cut in, and tell me that the project above (tiered, webforms) is the same as MVC. He went on to describe the following:
- Views are just ASPX pages
- Controllers are just page-behinds
- Models are just data objects
Long story short - we got into an unsettled debate over whether the project described above (tiered webforms) constitutes MVC or not.
Can someone provide and answer to this debate?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不。 MVC 主要用于强关注点分离。控制器和视图没有绑定在一起，除了传递模型（或不传递模型）之外，不知道对方。单个控制器可用于呈现许多视图，其中背后的 aspx 代码与单个 aspx 页面紧密相关，因为它们都是同一分部类的一部分。模型的差异较小，除了在大多数 MVC 应用程序中模型不是实际的域数据类型，而是一些可用于渲染视图的组合之外。
MVC 的另一个不同之处是严格的分层文件夹结构和命名约定。这促进了最佳实践，并再次促进了关注点分离。
微软创建 asp.net mvc 框架是有原因的，尽管您可能能够使用路由等在 Web 表单中模拟 mvc 的一些感觉，但它不是、也永远不会是完全相同的东西。
另外，虽然这偏向于 ASP.NET MVC，但显然还有许多其他版本。我建议您也查看 FubuMVC 。
no. mvc is used mostly for strong separation of concern. the controller and view are not tied together and have no knowledge of the other besides the passing of a model (or not). a single controller can be used to render many views, where as the aspx code behind is strongly tied to a single aspx page, as they are all part of the same partial class. the model is less different, other than to say in most mvc applications the models are not the actual domain data types, but rather some composite that can be used to render the view.
the other thing that is different with mvc is the rigid heirarchical folder structure and naming convention. this promotes best practices and, again, separation of concern.
microsoft created the asp.net mvc framework for a reason, and though you may be able to emulate some the feel of mvc in web forms using routing and such, it is not and won't ever be quite the same thing.
also, while this has been slanted toward asp.net mvc, there are obviously many other flaors out there. i'd suggest you check out FubuMVC as well.
由于 模式 MVC 与任何特定的技术（WebForms、WinForms、ASP.NET MVC 等）。
因此，在 WebForms 中实际实现 MVC 是很有可能的。
CodeBehind 文件可以被视为控制器，但从技术上讲这是不正确的：代码隐藏文件和 aspx 文件都被编译为一种类型（因为它们是部分类），因此在这件事上不存在控制器类型和视图类型；）
但我们可能认为这种差异很小。
WebForms 可以被视为实现 MVC 模式的东西，承认它是一个非常丑陋的实现，很容易搞砸。但是一旦它被搞乱了（就像通常发生的那样），视图和控制器之间分离关注点的整个想法至少就被违反了，所以一旦这种分离变得模糊或消失，我们应该说它不再是 MVC 了。
简历：WebForms 可以被视为 MVC 模式的实现，机器人在这个实现中很难遵循这种模式，所以它很少保留 MVC 并停留在其概念之内。
As a pattern MVC is agnostic from any specific technology (WebForms, WinForms, ASP.NET MVC, etc).
So it is very possible to actually do MVC in WebForms.
CodeBehind files can be treated as controllers, but technically it is incorrect: both code behind file and aspx file are compiled into just ONE type (as they are partial classes), so there is no controller type and view type in this matter ;)
But we may consider this difference as a minor one.
WebForms CAN be viewed as something implementing MVC pattern, admitting that it is a very ugly implementation that can be very easily messed up. But once it is messed up (as it usually happens), the whole idea of separation concerns between View and Controller at least is violated, so once this separation blurred or disappears we should say that it is not MVC anymore.
Resume: WebForms could be treated as an implementation of the MVC pattern, bot it is really hard to follow this pattern in this implementation so it very rarely remains MVC and stays within its concepts.
坦率地说，技术主管是错误的。
以前从未使用过真正的 MVC 框架的人们普遍存在一种误解，认为“MVC”只是 Web 表单的一种不同风格，而事实上，事实并非如此。
要理解为什么会出现这种情况，您需要了解 MVC、架构模式和ASP.NET MVC、微软构建的框架实现了 MVC 模式。
通常，技术主管和架构师等不太了解该主题的人会使用术语“MVC”来描述模式和框架，但不了解其主题两者之间的差异常常会导致混乱。
因此，需要明确的是，MVC 模式并不是什么新鲜事，它实际上是由许多框架实现的，例如：
Webforms 不是实现开箱即用的 MVC 模式的框架之一。
现在，您确实可以在 WebForms 中实现 MVC 模式，但是 Webforms更适合实现 MVP 风格模式，并且实际上有一些框架（比如这个）会在这方面为您提供帮助。
然而，技术主管不知道他在说什么的最大迹象是：
在应用程序中引入“层”与 MVC 无关。事实上，在分层架构中，MVC 应用程序将完全位于表示层内，与其他应用程序层无关。
使用 ASP.NET MVC 作为前端意味着您拥有一个位于使用 ASP.NET MVC 框架实现的逻辑层之上的表示层。这并不意味着您仅仅因为使用 MVC 就突然不再需要其他层。
相反，Webforms 只是分层架构中的表示层。仅仅因为您使用的是分层架构，并不意味着您正在使用 MVC 模式。
对于其他每一点：
视图只是 ASPX 页面
这不是真的。 ASPX 页面是非常复杂的野兽，并且与 MVC 视图之间有一个非常重要的区别：
它们旨在维护状态
它们具有页面生命周期和视图状态以及旨在维护之间的状态的整个系统。回发。
ASP.NET MVC 被设计为无状态的，因此视图不包含这样的复杂性。
控制器只是页面后面
这种说法完全没有抓住控制器的要点。
代码隐藏明确地知道与呈现 ASPX 页面的过程有关的所有内容。它了解页面上的控件、页面的状态、页面的生命周期，并且与视图紧密耦合。
代码隐藏也只会返回 1 件事。一个 aspx 页面。
控制器更加灵活，不仅可以返回视图，还可以用于控制渲染数据的不同表示的逻辑。例如，您可能希望将相同的数据呈现为标准 http 请求的 HTML，或呈现为 AJAX 请求的 JSON。
这是可能的，因为控制器逻辑和视图逻辑是松散耦合，这使得这成为可能。
模型只是数据对象
这是错误的。在任何类型的具有任何复杂性的 MVC 应用程序中，很少会将数据对象直接绑定到视图。简而言之，数据库中数据建模的方式很少能代表显示视图所需的数据。
例如，假设您有一条员工记录，其中包含“TitleId”。记录中的数据只是一个 int，但您需要向用户显示实际的文本值才能使其有意义。
因此，在大多数 MVC 应用程序中，您的“模型”实际上可以更准确地描述为“ViewModel”，并且完全独立于您的数据或域模型。
总结
你的技术主管是错误的，不仅在语义层面上是错误的，而且在“你不知道你在说什么”层面上是错误的。
希望有帮助。
To be blunt, the tech lead is wrong.
There is a common misconception amongst people that have never used a true MVC framework before, that "MVC" is just a different flavour of webforms, when in fact, nothing could be further from the truth.
To understand why this is the case, you need to understand the difference between MVC, the architectural pattern, and ASP.NET MVC, the framework built by microsoft that implements the MVC pattern.
Often, people such as tech leads and architects that don't quite understand the topic, will use the term "MVC" to describe both the pattern and the framework without understanding the difference between the two and this often leads to confusion.
So, to be clear, the MVC pattern is nothing new, and it is in fact implemented by a lot of frameworks such as:
Webforms is not one of the frameworks that implements an MVC pattern out of the box.
Now it is true that you could implement an MVC pattern in WebForms but Webforms is more suited to implementing an MVP style pattern and there are in fact framework around (such as this one) that will help you in this regard.
The biggest indicator that the tech lead has no idea what he's talking about however, is this:
Introducing "tiers" into your application has nothing to do with MVC. In fact, within a tiered architecture, an MVC application would sit entirely within the presentation tier and have nothing to do with the other application tiers.
Using ASP.NET MVC for your front end means that your have a presentation tier that sits on top of your logic layers that is implemented using the ASP.NET MVC framework. It doesn't mean that you've suddenly removed the need for the other tiers simply because you're using MVC.
Conversely, Webforms is just the presentation layer within the tiered architecture. Just because you're using a tiered architecture in no way implies that you're using an MVC pattern.
To each of the other points:
Views are just ASPX pages
This is not true. ASPX pages are very complex beasts and have one very major difference between MVC views:
They're designed to maintain state
They have this whole system of a page lifecycle and viewstate and controls that is designed to maintain state between postbacks.
ASP.NET MVC is designed to be stateless and as such, the views contain no such complexities.
Controllers are just page-behinds
This statement completely misses the point of controllers.
Codebehinds are explicitly aware of everything that is concerned with the process of rendering an ASPX page. It knows about the controls on the page, the state of a page, the lifecycle of the page and is very tightly coupled to the view.
A codebehind is also only ever going to return 1 thing. An aspx page.
Controllers are far more flexible and can return not only views, but they can be used to control the logic for rendering out different representations of your data. For example, you may want the same data to be rendered out as HTML for a standard http request, or rendered as JSON for an AJAX request.
This is possible because the controller logic and view logic are loosely coupled which is what makes this possible.
Models are just data objects
This is wrong. It's rare in any sort of MVC application with any sort of complexity that you'd bind your data objects directly to a view. Simply put, the way your data is modelled in the database will rarely represent the data that is required to display a view.
For example, say you have an employee record, which has a "TitleId". The data in the record would just be an int, but you'd need to display an actual text value to a user for it to make any sense.
So, in most MVC applications, your "Model" would actually be more accurately described as a "ViewModel" and is completely seperate from your data or domain models.
To summarise
Your tech lead is wrong, and not just wrong at a semantic level, but wrong in a "you-have-no-idea-what-you're-talking-about" level.
Hope that helps.