如何决定在 Web 应用程序中使用 MVC 或 3 层架构中的哪一个？
如果我们必须为 .Net 中的 Web 应用程序选择任何一种架构模式，哪一种是最好的，MVC 还是 3 层，如何决定？
If we will have to chose any one architecture pattern for web application in .Net, which one will be the best, MVC or 3 tier, How to decide ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Jeevan，
我认为不幸的是，您正在遵循许多刚接触 MVC 的开发人员所采取的一系列思路，因为您已经“被灌输”了这样一种信念，即 mvc（模型）中的“M”纯粹是一个 linq2sql 平面实现，仅此而已对于模型。并非如此......在我们的应用程序中，我们必须满足网络/桌面和手持设备的混合需求，所有这些设备都使用其中的各个通用功能领域。因此，我们创建了一个包含所有业务逻辑的“BLL/DAL”dll，在我们的 mvc 应用程序中被引用为“M”。我们的网络表单应用程序以及桌面应用程序中也使用了相同的“bll/dal”。在当前的一个应用程序中，我们使用 bll/dal dll 连接到 oracle 后端，并使用 MVC 纯粹作为 RESTful 服务，充当两个遗留系统之间的中介。考虑到我们的 bll/dal dll 的设计，如果业务需要，我们可以轻松地将其切换到 sqlserver。
所以简而言之，选择 MVC 或 3 层（我实际上认为你的意思是分层，而不是分层 [这更多地与功能/服务的物理分离相关]）的提议完全是一个没有实际意义的问题，因为它们正在聚合，而不是比不同的技术。
希望这会有所帮助 - 今天晚些时候我将尝试通过谷歌先生获取一些示例，以例证我的方法的完整性。
[编辑] - 来自 SO 上的类似问题；
N 层仅指实现的物理结构。这两者有时会混淆，因为 MVC 设计通常使用 N 层架构来实现。
MVC VS n层架构
简单来说，一个是对象/API设计，一个是系统架构；两人可以幸福地生活在一起。
Jeevan,
I think you're unfortunately following a train of thought that many developers new to MVC take insofar as you've been 'fed' a belief that the 'M' in mvc (model) is purely a linq2sql flat implementation and that's it for the model. Not so... in our apps we have to cater for a mixture of web/desktop and handheld devices all using various areas of common functionality within them. we therefore have created a 'BLL/DAL' dll with all our business logic that is referenced as the 'M' in our mvc apps. This same 'bll/dal' is used in our webforms apps as well as in our desktop apps. in one current app, we're hooking into an oracle backend with our bll/dal dll and using MVC purely as a RESTful service acting as an intermediary between two legacy systems. given the design of our bll/dal dll, we could just as easily switch that to sqlserver, should (as and when) the business require.
so in a nutshell, the proposition of choosing MVC or 3 tier (and i actually think you are meaning layered, rather than tiered [which relates more to physical separation of functionality/services]) is totally a moot point as they are converging, rather than disparate technologies.
hope this helps - i'll try to source some examples via mr google later today to exemplify the fullness of my approach.
[edit] - from a similar question here on SO;
N-tier just refers to the physical structure of an implementation. These two are sometimes confused because an MVC design is often implemented using an N-tier architecture.
MVC Vs n-tier architecture
in a nutshell, one is object/API design, one is system architecture; both can live happily together.
两者都是相当高级的概念，并且所有高级概念都没有明确的答案。此外，您可以非常成功地混合它们。例如，在表示层上有多层应用程序，只要您的应用程序足够大，满足需要（例如您有大型数据集群+分析层+报告层）。
每次您在这两者之间进行选择时，我建议您考虑以下几个方面：
这个列表当然可以继续下去，但我认为这 4 件事将使您走上正确的轨道。
根据我的经验，或多或少复杂的架构，现实生活系统（不是学术幻想的系统）从来都不是 MVC 或 3 层，但总是很多东西的混合:)
Both are pretty high level concepts, and with all high level concepts there are no definitive answer. Moreover, you can quite succesfully mix them. For example have multitier application on the presentation tier, provide your application is large enough that this is required(for instance you had large cluster of data + analytics layer + reporting layer).
Everytime you're choosing between those 2, I would suggest thinking about these aspects:
This list could go on of course, but I think these 4 things will get your on the right track.
From my experience architecture of more or less complex, real life system(that is not academic fantasy ones) is never MVC or 3 tier, but always is quite a mix of many things :)