将服务器端逻辑移动到javascript .. [英] Moving server side logic to javascript..
问题描述
大家好，
我在一家金融公司工作。我打算在移动服务器端向开发团队的其他人（15人）发表演示
逻辑到客户端javascript用于内部Intranet应用程序
重写。这种方法肯定会激起争论来自
硬核服务器端的Java人员，他们甚至想要在
服务器上做UI内容！由于我几乎被称为
组的JS或UI Guy，我的Boss希望听到每个
支持者的广泛PRO / CON。 />
就个人而言，我认为Javascript / Ruby是一种比Java更好的语言。
我的想法很简单。它是将大多数业务逻辑转换为客户端 -
方javascript，并且调用服务器端代码仅限于用户
角色并进行数据验证。这很简单。
这是我的参数列表
1. UI逻辑与服务器端数据处理的真正分离代码
（没有更多的服务器代码吐出客户端代码）
2.更好的用户体验和更快的响应
3.整个网络2.0的事情（没有页面刷新）:)
4.从服务器卸载客户端处理因此减少网络
流量（这不是一个强有力的论据吗？）
请记住这是一个内部应用程序。即使有人在页面后面找出了
JS逻辑并尝试通过发布到
Servlet来破解应用程序，它们将受到其登录角色和数据的限制
验证将处理提交的任何虚假数据。
任何反馈非常感谢帮助这个孤独的UI家伙！
-Pete
< ra ******* @ gmail.comwrote：
< blockquote class =post_quotes>
大家好，
我在一家金融公司工作。我计划给开发团队的其他人（15人）提供一个
的演示文稿
这里将服务器端逻辑移动到客户端javascript
用于内部Intranet应用程序重写。
这种方法肯定会激起争论来自
核心服务器端Java人员想要做UI的事情
甚至在服务器上
！由于我几乎被称为该团队的JS或UI Guy，我的Boss希望听到来自每个支持者的广泛的/ b $ b频谱的PRO / CON。 />
就个人而言，我认为Javascript / Ruby是一种比Java更高效的b / b $ b语言。
好吧，甚至没有提到（特别是对你的Java程序员）或
你会发现自己没有被认真对待。
我的想法很简单。它是将大多数业务逻辑转换为客户端javascript的
并且调用服务器端代码
仅限于具有数据验证的用户角色。这就像
一样简单。
虽然（如果它们是好的）服务器端Java程序员将
已经具有以下形式的业务逻辑可用组件和
将质疑重新创建已存在的成本。或者他们会指出，如果他们实施新的业务逻辑，他们将能够轻松地在以后的项目中重新使用它。或者他们会指出，为了在服务器上验证
，他们仍然需要服务器上的大部分业务逻辑，所以任何新的东西都会被写两次。
以下是我的参数列表
1. UI逻辑与服务器端数据的真正分离
处理代码（没有更多服务器代码吐出
客户端代码）
你不只是说你我们计划将业务逻辑放在客户端上吗？
将所有用户界面代码放在客户端上是有道理的（尽管它是
并不总是实用的：考虑在客户端上排序一个包含40万笔交易的桌子
。这不会发生。）
考虑到这一点仔细分离。要做的是一个情况
，服务器不关心客户端的细节（网页
浏览器，桌面客户端等）和客户端并不关心服务器上运行的
技术（Java，ASP，.NET，Ruby等）。那个分离的方式将是两者如何沟通（SOAP（Web服务），
自定义XML，JSON或其他什么，以及它们传输的消息/数据）。 />
在这一点上调整分离，你正在为可以与任何类似通信接口一起使用的
a浏览器构建UI组件，并且
服务器代码可以为任何客户提供相同的界面。
2.更好的用户体验和更快的响应
不一定跟随，因为客户端桌面机器的概率
具有不同的功能，并且包括许多不是那么新的而不是
必然要升级到不久的将来，一个全新的双b / b $ b或四核，多核CPU服务器，配备4GB内存和最新硬盘
（具有适当的RAID跨越）可以拥有服务器端代码飞行，
组织范围，
4,000左右（过去一年左右，他们真的非常che
）。
3.整个网络2.0件事（没有页面刷新）:)
流行语不是制定战略性或建筑性的b
决定的理由。
如果你提到它，就可以准确地被问到什么是web 2.0了。意思是，如果你所说的都是没有页面刷新而被嘲笑。
你有任何实际的设计经验吗？
刷新了吗？赔率是我们正在谈论Windows 2000台式机
所以没有机会将IE 6升级到IE 7（这方面要好得多，这个方面是b $ b）因此需要将大量的工作投入到没有工作的情况下，IE 6逐渐积累了更多的客户端PC的内存，并且随着时间的推移，
的运行速度越来越慢。
4.从服务器卸载客户端处理因此减少了
网络流量（这不是一个强有力的论据吗？）
正如我上面暗示的那样，从服务器卸载工作的需求是减少，现代网络可以处理流量（特别是如果
使用HTTP压缩）。
请记住这是一个内部应用程序。即使有人在页面背后的JS逻辑中找出并且试图通过向Servlet发布
来破解应用程序，他们也会被他们的登录限制
角色，数据验证将处理提交的任何虚假数据
。
所以你不会向服务器端的Java程序员出售这个想法
他们有更少的工作要做，因为他们会必须重复你在客户端上做的大部分工作才能验证提交的内容。
任何反馈非常感谢帮助这个孤独的UI家伙！
我原本想到的（特别是在财务
机构和内部申请的情况下）是一个财务的b
。可能增加/降低生产力的影响
的系统用户，与R& D的成本/收益相对应，
设计，实施，持续维护，和他们的连锁效应
用于未来的项目。
Richard。
2月12日上午7:56，兔子...... @ gmail.com < rabbit ... @ gmail.comwrote：
>
我在一家金融公司工作。我打算在移动服务器端向开发团队的其他人（15人）发表演示
逻辑到客户端javascript用于内部Intranet应用程序
重写。这种方法肯定会激起争论来自
硬核服务器端的Java人员，他们甚至想要在
服务器上做UI内容！由于我几乎被称为
组的JS或UI Guy，我的Boss希望听到每个
支持者的广泛PRO / CON。 />
就个人而言，我认为Javascript / Ruby是一种比Java更好的语言。
我的想法很简单。它是将大多数业务逻辑转换为客户端 -
方javascript，并且调用服务器端代码仅限于用户
角色并进行数据验证。这很简单。
这是我的参数列表
1. UI逻辑与服务器端数据处理的真正分离代码
（没有更多的服务器代码吐出客户端代码）
2.更好的用户体验和更快的响应
3.整个网络2.0的事情（没有页面刷新）:)
4.从服务器卸载客户端处理因此减少网络
流量（这不是一个强有力的论据吗？）
请记住这是一个内部应用程序。即使有人在页面后面找出了
JS逻辑并尝试通过发布到
Servlet来破解应用程序，它们将受到其登录角色和数据的限制
验证将处理提交的任何虚假数据。
任何反馈非常感谢帮助这个孤独的UI家伙！
我同意Richard的观点。 JavaScript可能比Java更高效，但如果Java代码已经存在，则不会是b $ b。验证码永远不应该离开服务器，因此需要复制。
但学习和实现JavaScript来做你的事情
describe仍然充满乐趣和趣味。可能有一种方法可以加速应用程序的部分内容，但是整个网站（如果它是一个很大的部分）为
一页似乎过分了一件好事。
这些单页应用程序的URL是可收藏的。雅虎！使用
很好。背板的使用可能不是。
http://maps.yahoo。 com /
http://www.backbase.com/
这是一个有趣的客户端MVC架构实验（
是错误的）
http://trimpath.com/project/wiki/SteveYen
彼得
Hi Everyone,
I work for a financial company. I am planning to give a presentation
to rest of the development team (15 people) here on moving server side
logic to client-side javascript for an internal intranet application
rewrite. This approach will definitely stir up hot debate from
hardcore server-side Java folks who wants to do UI stuff even on the
server!. Since I am pretty much known as the JS or UI Guy of the
group, my Boss wants to hear the broad spectrum of PROs/CONs from each
proponent.
Personally, I think Javascript/Ruby is a more productive language than
Java.
My idea is simple. It is to convert most business logic to client-
side javascript and have calls to server-side code restricted to user
roles with data validation. Thats as simple as it gets.
Here are my list of arguments
1. True separation of UI logic from server-side data processing code
(no more server code spitting out client-side code)
2. Better user experience with faster response
3. The whole web 2.0 thing (no page refresh) :)
4. Offload client processing from server therefore reducing network
traffic (not really a strong argument is this?)
Keep in mind this is an internal app. Even if someone figures out the
JS logic behind the page and try to hack the app by posting to
Servlets, they will be restricted by their login role, and data
validation will take care of any bogus data being submitted.
Any feedback greatly appreciated to help this lonely UI guy!
-Pete
<ra*******@gmail.comwrote:Hi Everyone,
I work for a financial company. I am planning to give a
presentation to rest of the development team (15 people)
here on moving server side logic to client-side javascript
for an internal intranet application rewrite.
This approach will definitely stir up hot debate from
hardcore server-side Java folks who wants to do UI stuff
even on the server!. Since I am pretty much known as the
JS or UI Guy of the group, my Boss wants to hear the broad
spectrum of PROs/CONs from each proponent.
Personally, I think Javascript/Ruby is a more productive
language than Java.Well don''t even mention that (particularly to your Java programmers) or
you will find yourself not being taken seriously at all.
My idea is simple. It is to convert most business logic to
client- side javascript and have calls to server-side code
restricted to user roles with data validation. Thats as
simple as it gets.While (if they are any good) the server-side Java programmers will
already have the business logic in the form of re-useable components and
will question the cost of re-creating what already exists. Or they will
point out that if they implement new business logic they will be able to
easily re-use it later projects. Or they will point out that in order to
validate on the server they will still need most of the business logic on
the server so anything new will be being written twice.
Here are my list of arguments
1. True separation of UI logic from server-side data
processing code (no more server code spitting out
client-side code)Didn''t you just say you were planning on putting the business logic on
the client?
Putting all the user-interface code on the client makes sense (though it
is not always practical: consider sorting a table of 400,000 transactions
on the client. That is not going to happen).
Consider this ''separation'' carefully. The thing to go for is a situation
where the server doesn''t care about the specifics of the client (web
browser, desktop client, etc.) and the client doesn''t care about the
technology running on the server (Java, ASP, .NET, Ruby, etc). That
separation would be about how the two communicated (SOAP (web services),
custom XML, JSON or whatever, and what messages/data they transmitted).
Pitch the separation at that point and you are building UI components for
a browser that can be used with any similar communication interface, and
the server code can provide the same interface to any client.
2. Better user experience with faster responseThat doesn''t necessarily follow, as the odds are client desktop machines
are of varying capability and include many that are not that new and not
necessarily due for an upgrade in the near future, while a brand new dual
or quad, mult-core CPU server with 4GB RAM and the latest hard disks
(with appropriate RAID spanning) can have the server side code flying,
organisation wide, for
4,000 or so (they really have got very cheep over
the last year or so).
3. The whole web 2.0 thing (no page refresh) :)Buzzwords are not a reason for making strategic or architecturally
decisions.
If you mention it be ready to be asked precisely what "web 2.0" means,
and to be ridiculed if all you say is "no page refresh".
Have you any practical experience of designs where the page is never
refreshed? Odds are we are talking about Windows 2000 desktop machines
and so no opportunity to upgrade IE 6 to IE 7 (which is far better in
this respect) and so the need to put a great deal of work into not having
IE 6 gradually accumulate ever more of the client PC''s memory, and
operate slower and slower as time goes on.
4. Offload client processing from server therefore reducing
network traffic (not really a strong argument is this?)As I implied above, the need to offload work form the server is
diminishing, and modern networks can handle the traffic (particularly if
HTTP compression is employed).
Keep in mind this is an internal app. Even if someone figures
out the JS logic behind the page and try to hack the app by
posting to Servlets, they will be restricted by their login
role, and data validation will take care of any bogus data
being submitted.So you will not be selling the server-side Java programmers on the idea
of them having less work to do, as they will have to repeat much of what
you do on the client in order to validate whatever is submitted.
Any feedback greatly appreciated to help this lonely UI guy!I would have thought (and particularly in the context of a financial
institution, and for an internal application) the case to make would be a
financial one. The impact of potentially increased/decreased productivity
of the users of the system, with and against the cost/benefit of R&D,
design, implementation, ongoing maintenance, and their knock-on effects
for future projects.
Richard.
On Feb 12, 7:56 am, "rabbit...@gmail.com" <rabbit...@gmail.comwrote:>
I work for a financial company. I am planning to give a presentation
to rest of the development team (15 people) here on moving server side
logic to client-side javascript for an internal intranet application
rewrite. This approach will definitely stir up hot debate from
hardcore server-side Java folks who wants to do UI stuff even on the
server!. Since I am pretty much known as the JS or UI Guy of the
group, my Boss wants to hear the broad spectrum of PROs/CONs from each
proponent.
Personally, I think Javascript/Ruby is a more productive language than
Java.
My idea is simple. It is to convert most business logic to client-
side javascript and have calls to server-side code restricted to user
roles with data validation. Thats as simple as it gets.
Here are my list of arguments
1. True separation of UI logic from server-side data processing code
(no more server code spitting out client-side code)
2. Better user experience with faster response
3. The whole web 2.0 thing (no page refresh) :)
4. Offload client processing from server therefore reducing network
traffic (not really a strong argument is this?)
Keep in mind this is an internal app. Even if someone figures out the
JS logic behind the page and try to hack the app by posting to
Servlets, they will be restricted by their login role, and data
validation will take care of any bogus data being submitted.
Any feedback greatly appreciated to help this lonely UI guy!I agree with Richard. JavaScript may be more productive than Java but
not if the Java code already exists. Validation code should never
leave the server and so will need duplication.
However learning and implementing the JavaScript to do the things you
describe is still fun and interesting. There may be a way to speed up
parts of the application but the whole site (if it is a big one) as
one pages seems like overdoing a good thing.
The URLs of these one-page apps are are bookmarkable. The Yahoo! use
is good. The backbase use is probably not.
http://maps.yahoo.com/
http://www.backbase.com/
Here is an interesting client-side MVC architecture experiment (that
is buggy)
http://trimpath.com/project/wiki/SteveYen
Peter
这篇关于将服务器端逻辑移动到javascript ..的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
