在“无页面”应用程序中使用 jQuery JSON 请求的 API 驱动设计有哪些缺点？ ASP.NET MVC 3 下的设计？
这就是我的设想。采取一个数据库（该数据库广泛使用 sql server 2008 空间类型/查询）。基于存储库模式构建数据访问。设置控制器以基于高度“可发现”的 url 方案（/Products/TVs/Sony/27in/All 等...）返回 JSON 数据。
在视图之间共享的单独文件中构建核心 JavaScript 框架，以便将大部分 js 代码缓存在客户端。
使用核心框架方法来调用这些可发现的 url，通过 JSON 调用提取数据，然后利用 MS jQuery 模板将其呈现在客户端上。
确保这些调用在服务器端被缓存（ala 输出缓存），尽可能避免对数据库的调用（如果可能）。
这样做，我想象过去在控制器中发生的许多存储库调用现在将在视图中发生，使用核心框架 - 应该释放服务器上的大部分负载，将一些工作转移到客户端。
由于没有这种设计的经验，我没有预见到这种设计的哪些缺点？有没有关于此类主题的好文章？我发现在 ZURBlog 上（虽然基于 Rails）。
Here's what I'm envisioning. Take a database (this one uses sql server 2008 spatial types/queries extensively). Build data access based on repository pattern. Setup controllers to return JSON data, based on a highly "discoverable" url scheme (/Products/TVs/Sony/27in/All, etc...).
Build a core javascript framework, in a separate file shared amongst the views so that the majority of the js code is cached on the client side.
Use the core framework methods to call those discoverable urls, pulling data via a JSON call, then utilize the MS jQuery templates to render it on the client.
Ensure these calls are cached, server side (ala output caching), as much as possible to avoid calls to the database if possible.
Doing this, I imagine many of the repository calls that used to happen in the controller would now be occurring in the view, using the Core framework - should free up much of the load on the server, moving a bit of the work to the clients.
Having no experience with this design, what drawbacks of this design am I not foreseeing? Any good articles out there about this sort of subject? I found a bit on ZURBlog (rails based though).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
明显的缺点是你 100% 依赖 Javascript。
您可能会让没有 Javascript 功能或 Javascript 功能有限的客户望尘莫及。
您的网站可能在搜索引擎中表现不佳，除非您还提供 HTML 版本。
可能存在可访问性问题。
纯 Javascript 网站当然是可能的，但网络的基线仍然是 HTML。您可能最好从基本的 HTML 页面开始，然后使用 Javascript 和纯 JSON 数据传输逐步增强它们，以便在可用的情况下加快页面加载速度。
The obvious drawback is that you're relying 100% on Javascript.
You may be leaving clients without or with limited Javascript capability in the dust.
Your site probably won't do very well in search engines, unless you also serve an HTML version.
There may be accessibility problems.
Pure Javascript sites are certainly possible, but the baseline for the web is still HTML. You may be better off starting with basic HTML pages and progressively enhance them using Javascript and JSON-only data transfer for faster page loads where available.