扩展 MVC 与扩展多层应用程序
据我所知，可以分布式多层应用程序以利用可扩展性。也就是说，当您的 Web 应用程序需要的资源超出单个服务器所能提供的资源时，您只需分发您的应用程序即可。
您可以将持久层放在一台服务器中，将业务层放在另一台服务器中，将表示层放在第三台服务器中。
此外，例如，您可以将业务层划分为许多服务，并将每个服务放在单独的服务器中来处理这么多请求。
由于多层应用程序本质上是通过 SOAP、Sockets、.Net Remoting 或 RMI 等中间件进行通信的组件，因此通过进一步分发其组件来扩展应用程序将相当容易。
问题是，使用 MVC 架构而不是 N 层架构设计的应用程序怎么样？据我所知，模型、视图和控制器驻留在一台机器中，那么如何分发 MVC 架构的 Web 应用程序？
问候，
As far as I know, multi-tier applications can be distributed to exploit scalability. That is, when your web application demands more resources than a single server can serve, you just distribute your application.
You can put the persistence tier in one server, the business tier in another and the presentation in a third server.
Furthermore, you can, for example, divide the business tier into many services and put each service in a separate server to cope with those many requests.
Because multi-tier applications, in essence, are components that communicate together by a middle-ware like SOAP, Sockets, .Net Remoting or RMI, it would be fairly easy to scale the application by further distribute its components.
The question is, what about an application that is designed using MVC architecture instead of N-Tier architecture?? As far as I know, models, views and controllers reside in a single machine, so how can someone distribute an MVC architectured web application??
Regards,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您可以调用控制器中的 Web 服务来获取数据，那么您将无法调用另一个系统上的业务层。我对mvc的理解是它旨在模式化系统的应用程序流程。它并不意味着业务层的结束或必须将业务层和领域层放在同一系统上。
if you can call a web service in your controller to get data what stops you from calling a business layer that is on another system. My understanding of mvc is that it is meant to patternize application flow of the system. it does not mean end of business layer or having to put business and domain layers on the same system.
应用程序的所有部分必须位于一台服务器上。使用 MVC 应用程序，您可以通过复制 iis 实例来扩展架构。例如，默认情况下，您有一台带有 iis 服务器的计算机和一个站点。对于需要重新组织实例的规模，例如添加一些 iis 服务器（默认的副本）（称为后端服务器）并添加平衡负载到后端的服务器（称为前端）
All part of application must be on one server. With MVC application you can scale architecture by copy iis instance. For example by default you have one computer with iis server and one site on it. For scale that you need to reorganize you instance like add some iis servers (the copy of you default) (it's call back-end servers) and add server witch balancing load to back-end (it's call front-end)
我目前正在使用 CakePHP（一个 MVC 框架）来解决这个问题。我已经对系统的数据库进行了分片，这最终是扩展的瓶颈。
在应用程序级别，模型、视图和控制器代码存在于应用程序服务器的每个实例上。控制器和视图级别按正常方式工作。所有的魔力都发生在模型的代码中。在进行读取或写入之前，模型将向目录服务器发出请求，以确定数据存储在哪个分片上，或者在新条目的情况下，应将其添加到哪个分片。
不过，数据的存储方式略有变化。我使用 MySQL 作为键/值存储，并且不使用联接，类似于 什么FriendFeed 做到了。
最终，这使得任何熟悉 MVC 设计范例的人都可以非常快速地熟悉该系统。在控制器和视图级别工作的开发人员甚至不需要了解系统是如何分片的（在大多数情况下）。
I'm currently working on this with CakePHP, which is an MVC framework. I've sharded the database for the system, which is ultimately the bottleneck in scaling.
While at the application level, the models, views and controller code exist on each instance of an application server. The controller and view levels work as they would normally. All the magic takes place in the code for the model. Before doing a read or write, the model will make a request to a directory server to figure out which shard the data is being stored on, or in the case of a new entry, which shard it should be added to.
How data is stored changes a bit though. I use MySQL as a key/value store and I don't use joins, similar what FriendFeed did.
Ultimately, this allows anyone familiar with the MVC design paradigm to come up to speed very quickly on the system. Developers working at the controller and view level don't need to even understand how the system is sharding (for the most part.)