基于 widget 的 MVC 应用程序的架构
我正在寻找有关我们计划使用 ASP.NET MVC 提供的 Extranet 应用程序的应用程序体系结构的指针。
将有大约 50 种实体类型和大约 200 个用户。主要实体将拥有2M+记录。
用户被分成小组，通常每组 2 或 3 人。每个群体都有不同的信息需求。因此，我们计划开发许多小部件，用户可以将它们组合在一起以制作个性化的应用程序。忽略窗口/小部件管理的 UI 问题，我想到了实现此目的的几种方法：
1）为每个小部件使用 Ajax，并与 Steve Sanderson 的 knockout.js 提供一些同步通过一些巧妙的规划，这可以解决一些问题同一字段的多个副本同时出现在屏幕上。我不喜欢这种方法的是，许多小部件需要相同的数据，但会单独请求它。即使使用服务器端缓存来减少数据库查询，这仍然会生成大量不必要的 http 请求。
2) 通过组装所有必需的小部件来构建页面服务器端。这类似于 OrchardCMS 所做的事情。我正在更详细地研究这一点。
3) 将其构建为一个 HTML5/JS 应用程序，并使用 Websockets 来管理通信。这感觉太新了。
所以：任何想法 - 这个问题以前是否已经解决过 - 如果是，在哪里/什么/如何解决。
I'm looking for pointers for an application architecture for an extranet application that we plan to deliver with ASP.NET MVC.
There will be about 50 Entity types, and around 200 users. The main entities will have 2M+records.
The users are divided into small groups, typically 2 or 3 people a group. Each group has different information requirements. As such we are planning on developing a number of widgets which the users can group together to make their personalized application. Ignoring the UI issues of window/widget management, several ways of achieving this spring to mind:
1) use Ajax for each widget and provide some synchronization with perhaps Steve Sandersons knockout.js With a bit of clever planning this could solve some of the issues of multiple copies of the same field being on the screen at once. What I don't like about this approach is that lots of the widgets need the same data, but will be requesting it separately. Even with server-side caching to reduce DB queries this is still going to be generating a huge number of unnecessary http requests.
2) Build the pages server side by assembling all the required widgets. This would be akin to what is done with OrchardCMS. I'm taking a look at that in a bit more detail.
3) Build it more as a HTML5/JS app with Websockets to manage the communication. This feels like too much too new.
So: any ideas - has this been solved before - if so, where/what/how.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么不选择#1 和#2 的组合。 #3 听起来很诱人，但您将遇到浏览器支持问题（此时）。当您渲染页面时，您知道页面所需的小部件的数量和类型。您可以使用小部件所需的所有数据创建统一的 XML 文档。
了解所有数据后开始创建文档。向服务器请求数据并缓存。然后，您可以将此文档下载到客户端，其中每个小部件可以查询单独的节点。小部件将在本地呈现，然后从文档中提取数据。
Why not choose a combination of both #1 and #2. #3 sounds enticing but you are going to have issues with browser support (at this time). When you are rendering the pages you know the number and type of widgets required for the page. You can create a unified XML document with all of the data required by the widgets.
Begin creating the document when you know all of the data. Request the data on the server and cache it. You could then download this document to the client where each widget could query a seperate node. The widgets would render locally and then pull data from the document.