Web 应用程序：客户端域逻辑
我们看到越来越多的 Web 应用程序工作在客户端完成。 UI 操作、输入预验证（当然不是验证的最后手段）、小部件、效果等。
如果决定将域逻辑放在用 Javascript/GWT/其他内容编写的客户端怎么办？ 服务器仅提供数据库基础设施。
这对你来说可行吗？ 对这个想法有什么经验、建议或意见吗？
编辑： 如果你四处看看，你会发现可以编写整个应用程序< /a> 没有一行 php/python/java/whatever。
We see more and more work for web-applications done on client side. UI manipulation, input-pre-validation (not as last resort of validation, of course), widgets, effects, etc, etc.
What if one decides to put domain logic on client side written in Javascript/GWT/anything else? The server just provides database infrastructure.
Does this sound viable to you? Any experiences, advice or opinions to this idea?
Edit:
If you poke around, you'll realize that it is possible to write entire applications without a single line of php/python/java/whatever.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我谨不同意这里的其他海报。 事实上，我已经实现了这样一个拼字游戏，几乎完全使用客户端逻辑。 事实上，我想做很多事情来使其更加客户端密集。 GMail 在客户端做了大量的工作。
然而，出于实际原因，有些事情需要在服务端进行管理。 例如，服务器需要给用户一些图块，然后用户可以告诉服务器他将这些图块放在哪里，服务器需要验证这些槽是否为空，因为服务器永远不能完全信任客户端（客户端总是可以被劫持） ，如果不是通过脚本，则通过嗅探 HTTP 流量并进行修改）。
有很多技术，例如 ADO.NET 数据服务通过 RESTful 接口公开数据库中的 CRUD 操作，以及 CouchDB 直接通过 JavaScript 存储/管理数据对象。 此外，丰富的客户端库（如 jQuery 或 Moo Tools）确实推动客户端做越来越多的事情。
如果你仔细想想，Flash 的作用主要是在客户端完成所有 UI 和交互工作。 一些 Adobe Flex 应用程序非常棒。 我最近使用了一个用于 Google 分析的工具，它可以在客户端呈现图表、旋转以及所有这些。 服务器只提供数据服务。 即便如此，Google Gears 和 Firefox（我相信是 3.2？）现在提供客户端存储，这使得断开连接的应用程序场景变得更加有趣。
I respectfully disagree with the other posters here. In fact I have implemented just such a scrabble board game, using almost entirely client side logic. In fact, there are many things that I would like to do to make it even more client-side intensive. GMail does a tremendous amount of work on the client side.
However, there are some things that need to be managed on the serve side for practical reasons. For example the server needs to give the user some tiles and the user can then tell the server where he put those tiles and the server needs to verify those slots are empty because the server can never completely trust the client (the client can always be hijacked, if not through the script then by sniffing the HTTP traffic and modifying that).
There are a lot of technologies, some like ADO.NET Data Services to expose CRUD operations in the DB through a RESTful interface, and CouchDB to store/manage data objects directly through JavaScript. Also, rich client side libraries like jQuery or Moo Tools are really pushing the client to do more and more.
And if you think about it, flash is a lot about doing all the UI and interaction stuff on the client side. Some of the Adobe Flex applications are just awesome. I recently used one for Google analytics which renders the graphs, pivoting and all that on the client side. The server just serves the data. Even so Google Gears and Firefox (3.2 I believe?) now provide client side storage which makes disconnected application scenarios all that more interesting.
这些东西都很好，但请记住，如果有人禁用了 javascript，您将需要能够处理该问题并在用户弄乱您的数据库之前验证服务器上的输入。 因此，您可以在客户端放置任何您想要的内容，但您还需要在服务器端验证它。
Those things are all nice, but remember that if someone disables javascript you'll need to be able to handle that and validate input on the server before your users mess with your database. So you could put whatever you want on the client side, but you'll need to also verify it on the server side.
我认为这不是一个可行的想法。 有许多的原因。
总而言之，虽然客户端代码非常适合为用户提供比网页感觉更像应用程序的感觉，但为了网站的安全性和可访问性，这两种技术需要同时实现。
This is not a viable idea in my opinion. There are a number of reasons for this.
All in all, while client-side code is really nice for providing users with a more application like feel than a web page feel, in order for the security and accessibility of the website, the two techniques need to be both implemented.
我认为这是不可行的，至少如果你的目标是一致性和速度的话。 将大量逻辑放入 Javascript 中会给浏览器带来大量工作，这意味着客户端速度很慢。 另外，不要忘记所有浏览器都有自己的小怪癖。
I would think that would not be viable, at least if you are aiming for consistency and speed. Putting a lot of logic into say Javascript would cause a lot of work for the Browser, which means a SLOW client. Also, Don't forget all browsers have their little quirks.
取决于应用程序以及您想要如何使用它并重用代码。
客户端 JavaScript 实际上是特定于 Web 浏览器的。
域对象和实体可以在其他应用程序（桌面、Web 服务等）中重用，
更不用说当您的应用程序变得越来越大时，下载时间也会越来越长。
当然，任何人都可以立即复制粘贴您的代码并克隆您的应用程序。
Depends on the application and how you want to use it and re-use the code.
Client side javascript is really specific to web browsers.
Domain objects and entities can be reused in other applications (desktops, web services, etc)
Not to mention when and if your app gets larger and larger, the download times will get longer and longer.
And of course, anyone can copy paste your code and clone your app in no time.
对于任何公共（和非公共）网络应用程序，有人尝试检查您的防御措施只是时间问题。 JavaScript 验证将是第一个被取消的。 因为您可以在浏览器中禁用它，甚至可以在使用应用程序时禁用/启用它以达到理想的效果。
实际上你应该有三个级别的验证。
UI 验证（可选）：首次检查用户输入。 快速响应，无需服务器往返 -> 用户很高兴+您的服务器很高兴您已经可以将他们从一定数量的无效请求中解放出来。
服务器端验证（必需）。 这里再次进行所有验证+业务逻辑规则。 您可能必须访问一些标准或第三方库来检查/验证/执行您必须执行的操作。 在这里，您可以实现 BL 级别的数据完整性。
数据库级验证（非常理想）。 最后一道防线。 通过使用外键/唯一键/等确保数据完整性。 约束+事务级保护，防止多个并行请求突然破坏您的 BL 级完整性。
如果你想做得对，事情就应该这样。
For any public (and non-public) web application it is only a matter of time before someone tries to check out your defenses. JavaScript validation will be the first to go. Since you can just disable it in browser, or even disable/enable it while working with your application to achieve the desirable effect.
You should have three levels of validation actually.
UI validation (optional): first-time check of user input. Quick response without server roundtrip -> user is happy + your servers are happy that you could free them from some amount of invalid requests already.
Server-side validation (required). Here goes all that validation again + business logic rules. You'll likely have to access some standard or third-party libraries to check/validate/do whatever you have to. Here you achieve your data integrity on the BL level.
Database-level validation (very desirable). Last perimeter of defense. Assurance of data integrity through the use of foreign key/unique key/etc. constraints + transaction-level protection from multiple parallel requests suddenly destroying your BL-level integrity.
That's how it should be if you want to do it right.
您可以在这里找到有关 Web 应用程序性能分析的精彩摘要：http://www .websiteoptimization.com/speed/tweak/psychology-web-performance/
简而言之，现代 Web 应用程序在性能改进方面努力争取 100 毫秒。 在如此短的时间内，依赖 http 延迟已经是一个问题。 因此，很多逻辑正在转移到客户端，只是为了减少与用户交互时的 http 调用次数。
有许多可用和正在开发的框架有助于构建复杂的客户端代码。 首先：jQuery (UI)、Dojo、MooTools、Prototype 等 - 这些更多的是通用框架，适合任何类型的客户端逻辑。
更准确地说：
这里有不同框架的全面概述 http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
You can find nice summary on the web app performance analysis here: http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/
In short, modern web applications struggle for 100ms in performance improvement. At such short timespan it's already a problem to depend on http latency. So a lot of logic is moving to the client side just to reduce number of http calls when interacting with user.
There are number of frameworks available and developing which help in building complex client-side code. For the beginning: jQuery (UI), Dojo, MooTools, Prototype, etc - these are more of a generic frameworks and suitable for any kind of client-side logic.
More precisely:
There's a comprehensive overview of the different frameworks here http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/