g*****g
发帖数: 34805 | 1 其实很清楚，在J2EE架构里，应用分为三层，presentation，business logic，
persistence。
其中，后面两层统称为后端。presentation为前端。
不熟悉j2ee没有关系，这个划分对所有服务器应用都是相同的，目的是最大化商业逻辑
的部分，从而最小化冗余的代码。逻辑层和存储层的划分，是为了让同样的逻辑可以使
用不同的存储，比如mysql和oracle。商业逻辑层和表现层划分的目的也是一样的，为
的是让同样的商业逻辑可以用完全异质的客户端来表现。
假定你要做一个非常简单的服务，echo service，需要支持不同的client, web client
, desktop client, mobile client。底下的代码就是你的商业逻辑层，你的后端。而
所有的不同client都是前端。
String echo(String input) {
return input;
}
如果你把这东西写到前端，那么所有的client都要实现一遍，改动的话，所有的client
也都要改。
如果你写一个web应用，假想一下你要支持mobile client，可以共享的代码部分就是后
端，不能共享的就是前端。 |
P********l
发帖数: 452 | 2 node.js 很怪异． 因为前端后端有相同的vm，可以轻易地把一些js实现的逻辑推到
browser里． |
d****i
发帖数: 4809 | 3 赞goodbug详解，J2EE的web tier, 原来的JSP, 后来的JSF等等好像全都不行了，现在
web tier的东西统统让位给JS来实现了，然后后端通过REST和其他两层talk。
client
【在 g*****g 的大作中提到】
: 其实很清楚，在J2EE架构里，应用分为三层，presentation，business logic，
: persistence。
: 其中，后面两层统称为后端。presentation为前端。
: 不熟悉j2ee没有关系，这个划分对所有服务器应用都是相同的，目的是最大化商业逻辑
: 的部分，从而最小化冗余的代码。逻辑层和存储层的划分，是为了让同样的逻辑可以使
: 用不同的存储，比如mysql和oracle。商业逻辑层和表现层划分的目的也是一样的，为
: 的是让同样的商业逻辑可以用完全异质的客户端来表现。
: 假定你要做一个非常简单的服务，echo service，需要支持不同的client, web client
: , desktop client, mobile client。底下的代码就是你的商业逻辑层，你的后端。而
: 所有的不同client都是前端。
|
g*****g
发帖数: 34805 | 4 不管你怎么弄，但凡你要同时实现一个mobile client，你在browser里实现的逻辑
就必须在mobile client再实现一遍。如果不是ui部分，你肯定要重复写不必要的代码。
我说的划分是在一个合理架构的前提下。实际上没有按着这个走，重复代码的事情是个
公司都有。
【在 P********l 的大作中提到】
: node.js 很怪异． 因为前端后端有相同的vm，可以轻易地把一些js实现的逻辑推到
: browser里．
|
P********l
发帖数: 452 | 5 重复代码是难免的．
对于屌丝级的应用可以用phonegap来最大限度地利用已有的js逻辑. 如果上规模了就要
写native app了．
码。
【在 g*****g 的大作中提到】
: 不管你怎么弄，但凡你要同时实现一个mobile client，你在browser里实现的逻辑
: 就必须在mobile client再实现一遍。如果不是ui部分，你肯定要重复写不必要的代码。
: 我说的划分是在一个合理架构的前提下。实际上没有按着这个走，重复代码的事情是个
: 公司都有。
|
p*****2
发帖数: 21240 | 6 我对goodbug对前后端的划分很赞同。我不明白为什么非要把后端再分为前端和大后端。
说到逻辑应该在前端还是在后端，我怎么感觉你这次跟以前的表现不一致呢？
这个决定因素不是什么代码重用，而是用户体验。逻辑往前端转移这个是不是大概10年
前从Ajax就开始了？你都放后端根本不能支持良好的用户体验。比如F最开始为了代码
重用mobile上一定要用web，结果死的很惨，最后还是要老老实实做native app，而且
mark都承认错误了。当然了，从长期来看，mobile UI的趋势还是会往web方向转移，因
为就有你提到的代码重用问题。当然现在还不成熟，但是你看G两条腿走路，就是等着
有这么一天Chrome登台呢。
如果理解了这些就能理解为什么node会火，为什么SPA是趋势，为什么会有这么多
client MVC， backbone, ember, angular, meteor 等等，为什么传统mvc会慢慢被淘
汰了。 |
g*****g
发帖数: 34805 | 7 我没有分过什么后端大后端。商业逻辑前移也从来不是什么好的做法，重复代码是完全
没有必要的。F做native app跟这个完全无关。F的做法是把一部分html/js的代码在不
同mobile平台
上重用，这些都是UI代码，不是商业逻辑。影响体验的是js跑得比native慢，或者开发
受到限制，而跟逻辑在哪里无关。
如果你要理解我的分法，想象一下不同平台都是Native代码，没法重用，所以最大限度
的把共同逻辑放在后端是唯一的办法。这是完全不影响体验的。
说了这么多，就是说明spring mvc, Ror, Django这些server mvc架构，在我定义里都
是前端。node跟jvm对应，如果上面跑的是mvc，当然也是前端。如果跑商业逻辑，当然
是后端。
端。
【在 p*****2 的大作中提到】
: 我对goodbug对前后端的划分很赞同。我不明白为什么非要把后端再分为前端和大后端。
: 说到逻辑应该在前端还是在后端，我怎么感觉你这次跟以前的表现不一致呢？
: 这个决定因素不是什么代码重用，而是用户体验。逻辑往前端转移这个是不是大概10年
: 前从Ajax就开始了？你都放后端根本不能支持良好的用户体验。比如F最开始为了代码
: 重用mobile上一定要用web，结果死的很惨，最后还是要老老实实做native app，而且
: mark都承认错误了。当然了，从长期来看，mobile UI的趋势还是会往web方向转移，因
: 为就有你提到的代码重用问题。当然现在还不成熟，但是你看G两条腿走路，就是等着
: 有这么一天Chrome登台呢。
: 如果理解了这些就能理解为什么node会火，为什么SPA是趋势，为什么会有这么多
: client MVC， backbone, ember, angular, meteor 等等，为什么传统mvc会慢慢被淘
|
p*****2
发帖数: 21240 | 8
我没说是你分的。我觉得你说的还是靠谱的。所谓逻辑前移其实也不是商业逻辑，是把
UI的逻辑前移了。以前UI不都要在server端来生成吗？商业逻辑前移我同意你说的。不
过以后部分商业逻辑在client端也不一定不可能。像Meteor就把前后端的概念搞模糊了。
node跟jvm对应，如果上面跑的是mvc，当然也是前端。如果跑商业逻辑，当然
这个很同意。只是node上貌似没有传统mvc，或者说没有流行的mvc，以后也不会流行。
所以还主要是后端。
【在 g*****g 的大作中提到】
: 我没有分过什么后端大后端。商业逻辑前移也从来不是什么好的做法，重复代码是完全
: 没有必要的。F做native app跟这个完全无关。F的做法是把一部分html/js的代码在不
: 同mobile平台
: 上重用，这些都是UI代码，不是商业逻辑。影响体验的是js跑得比native慢，或者开发
: 受到限制，而跟逻辑在哪里无关。
: 如果你要理解我的分法，想象一下不同平台都是Native代码，没法重用，所以最大限度
: 的把共同逻辑放在后端是唯一的办法。这是完全不影响体验的。
: 说了这么多，就是说明spring mvc, Ror, Django这些server mvc架构，在我定义里都
: 是前端。node跟jvm对应，如果上面跑的是mvc，当然也是前端。如果跑商业逻辑，当然
: 是后端。
|
b***e
发帖数: 1419 | 9 这个倒是不一定。现在客户端基本上都有javascript engine。一些纯粹的，不涉及数
据存取的business logic完全可以用javascript写，然后在不同的客户端运行，即使是
mobile的客户端。客户端运行的一个好处就是减少server side load，把纯计算的东西
自然的做distributed computing。
码。
【在 g*****g 的大作中提到】
: 不管你怎么弄，但凡你要同时实现一个mobile client，你在browser里实现的逻辑
: 就必须在mobile client再实现一遍。如果不是ui部分，你肯定要重复写不必要的代码。
: 我说的划分是在一个合理架构的前提下。实际上没有按着这个走，重复代码的事情是个
: 公司都有。
|
d******e
发帖数: 2265 | 10 goodbug的划分还是老web系统的看法。现在单页面复杂web app加上html5 local
storage.很多时候有向典型的windows app移动。自然一些计算和商业逻辑可以放到前
面。否则老的多页面web也就是哄哄小孩子玩的。
端。
【在 p*****2 的大作中提到】
: 我对goodbug对前后端的划分很赞同。我不明白为什么非要把后端再分为前端和大后端。
: 说到逻辑应该在前端还是在后端，我怎么感觉你这次跟以前的表现不一致呢？
: 这个决定因素不是什么代码重用，而是用户体验。逻辑往前端转移这个是不是大概10年
: 前从Ajax就开始了？你都放后端根本不能支持良好的用户体验。比如F最开始为了代码
: 重用mobile上一定要用web，结果死的很惨，最后还是要老老实实做native app，而且
: mark都承认错误了。当然了，从长期来看，mobile UI的趋势还是会往web方向转移，因
: 为就有你提到的代码重用问题。当然现在还不成熟，但是你看G两条腿走路，就是等着
: 有这么一天Chrome登台呢。
: 如果理解了这些就能理解为什么node会火，为什么SPA是趋势，为什么会有这么多
: client MVC， backbone, ember, angular, meteor 等等，为什么传统mvc会慢慢被淘
|
|
|
p*****2
发帖数: 21240 | 11
嗯。趋势是这样的。不过goodbug还是比那些所谓的大后端靠谱的多。起码goodbug承认
node是后端。
【在 d******e 的大作中提到】
: goodbug的划分还是老web系统的看法。现在单页面复杂web app加上html5 local
: storage.很多时候有向典型的windows app移动。自然一些计算和商业逻辑可以放到前
: 面。否则老的多页面web也就是哄哄小孩子玩的。
:
: 端。
|
s*******t
发帖数: 44 | |
g*****g
发帖数: 34805 | 13 没做过不要瞎说，你这么做是灾难性的。想想facebook, 算3个平台就好(web, ios,
android), 本来商业逻辑里有个bug, 偷偷fix就好了，没几个人知道。这下让你做进了
前端，就算是共享的js代码，本来一个build一个server deployment能解决，现在要做
三个
build，一个server deployment (web), 两个client deployment，亿万用户要更新app
才能fix，几个月都不见得能完全解决。另外，前端都是很容易hack的，把商业逻辑放
进前端，就不能避免商业逻辑被修改，属于把小鸡鸡伸在外面的做法。
而你的所谓减少server side load，这年头server白菜先不说。就说client, 光
android的机器高端和低端性能差距能有上100倍，你把client做胖了，哪是减少server
side load，你是直接让低端用户用不了。
没有把商业逻辑做进前端的，这个是常识。
【在 b***e 的大作中提到】
: 这个倒是不一定。现在客户端基本上都有javascript engine。一些纯粹的，不涉及数
: 据存取的business logic完全可以用javascript写，然后在不同的客户端运行，即使是
: mobile的客户端。客户端运行的一个好处就是减少server side load，把纯计算的东西
: 自然的做distributed computing。
:
: 码。
|
g*****g
发帖数: 34805 | 14 商业逻辑是不能放进前端的，无关安全的商业逻辑，又不需要多客户端或者不怕重复代
码，
你写进前端是可以实现的，但仍然不是什么好的做法。单页面web app +html5 local
storage，
无非是server mvc改成了client mvc，整个mvc都是前端，有区别吗？
【在 d******e 的大作中提到】
: goodbug的划分还是老web系统的看法。现在单页面复杂web app加上html5 local
: storage.很多时候有向典型的windows app移动。自然一些计算和商业逻辑可以放到前
: 面。否则老的多页面web也就是哄哄小孩子玩的。
:
: 端。
|
s***o
发帖数: 6934 | 15 现在这个mobile横行的时代商业逻辑放前端是找死的节奏。改个什么东西，还要果果
approve，还要求爷爷告奶奶你的用户升级
还有就是好虫说的dev cost问题，前端各种平台，你全都得写一遍，good luck with
that
前端都是巴不得越轻越好 |
P********l
发帖数: 452 | 16 没人说要把商业逻辑放到前端．server必须假定client来的数据都是无效的．这个没什
么可讨论的．
现在的问题是复杂的用户流程控制放哪里．JSP之类的server template把这些逻辑放到
server上，browser简单展示．这样的结果是很差的用户体验． 在V8出现之前别无选择．
现在，browser很自然地自己控制用户流程．server甚至可以（动态地决定）把一些计
算量大的步骤甩给browser去做．前端后端的界限变得越来越模糊．
ios android 上面的 native app 就没有这个福气了．
app
server
【在 g*****g 的大作中提到】
: 没做过不要瞎说，你这么做是灾难性的。想想facebook, 算3个平台就好(web, ios,
: android), 本来商业逻辑里有个bug, 偷偷fix就好了，没几个人知道。这下让你做进了
: 前端，就算是共享的js代码，本来一个build一个server deployment能解决，现在要做
: 三个
: build，一个server deployment (web), 两个client deployment，亿万用户要更新app
: 才能fix，几个月都不见得能完全解决。另外，前端都是很容易hack的，把商业逻辑放
: 进前端，就不能避免商业逻辑被修改，属于把小鸡鸡伸在外面的做法。
: 而你的所谓减少server side load，这年头server白菜先不说。就说client, 光
: android的机器高端和低端性能差距能有上100倍，你把client做胖了，哪是减少server
: side load，你是直接让低端用户用不了。
|
n****1
发帖数: 1136 | 17 能否举个例子说明哪些“计算量大的步骤”明明可以放前段， 却被iOS/Android限制了
的？
现在的很多chrome apps很强大， 完全可以离线运行， 包括离线代码编辑器。 这些
apps基本做到了消灭server side MVC的程度了。 可它再强大顶多也就iOS/Android
native app的级别啊!
当然如果你想拿客户的机器做grid computing， 那就当我没说。
择．
【在 P********l 的大作中提到】
: 没人说要把商业逻辑放到前端．server必须假定client来的数据都是无效的．这个没什
: 么可讨论的．
: 现在的问题是复杂的用户流程控制放哪里．JSP之类的server template把这些逻辑放到
: server上，browser简单展示．这样的结果是很差的用户体验． 在V8出现之前别无选择．
: 现在，browser很自然地自己控制用户流程．server甚至可以（动态地决定）把一些计
: 算量大的步骤甩给browser去做．前端后端的界限变得越来越模糊．
: ios android 上面的 native app 就没有这个福气了．
:
: app
: server
|
d****i
发帖数: 4809 | 18 所以后端要搞REST，这样即使是ios和android的native client, 也可以和browser一样。
》 ios android 上面的 native app 就没有这个福气了． |
P********l
发帖数: 452 | 19 误会了．我想说ios android的native app不能过多涉及ui以外的逻辑．
计算量大的步骤当然有．相信我好了．
【在 n****1 的大作中提到】
: 能否举个例子说明哪些“计算量大的步骤”明明可以放前段， 却被iOS/Android限制了
: 的？
: 现在的很多chrome apps很强大， 完全可以离线运行， 包括离线代码编辑器。 这些
: apps基本做到了消灭server side MVC的程度了。 可它再强大顶多也就iOS/Android
: native app的级别啊!
: 当然如果你想拿客户的机器做grid computing， 那就当我没说。
:
: 择．
|
l*********s
发帖数: 5409 | 20 for eg. , input validation. Server side you definitely has to implement this
based your business logic. But, you shall not avoid duplicating in frontend
otherwise user experience will suffer. The weakest link in distributed
applications is almost never about CPU, but the network latency/availability. |
|
|
b***e
发帖数: 1419 | 21 这个我还真作过。比如一些game, 逻辑是在客户端计算, 在server端验证和保存的。验
证比计算要简单。
app
server
【在 g*****g 的大作中提到】
: 没做过不要瞎说，你这么做是灾难性的。想想facebook, 算3个平台就好(web, ios,
: android), 本来商业逻辑里有个bug, 偷偷fix就好了，没几个人知道。这下让你做进了
: 前端，就算是共享的js代码，本来一个build一个server deployment能解决，现在要做
: 三个
: build，一个server deployment (web), 两个client deployment，亿万用户要更新app
: 才能fix，几个月都不见得能完全解决。另外，前端都是很容易hack的，把商业逻辑放
: 进前端，就不能避免商业逻辑被修改，属于把小鸡鸡伸在外面的做法。
: 而你的所谓减少server side load，这年头server白菜先不说。就说client, 光
: android的机器高端和低端性能差距能有上100倍，你把client做胖了，哪是减少server
: side load，你是直接让低端用户用不了。
|
g*****g
发帖数: 34805 | 22 那是为了animation的计算，属于前端。我以前给一家游戏公司干过，写过所有的
casino game，我怎么会不知道。
比如black jack, 发牌和计算输赢的部分怎么都不能放前端，老虎机，所有的随机数计
算和
payout不能放前端。
【在 b***e 的大作中提到】
: 这个我还真作过。比如一些game, 逻辑是在客户端计算, 在server端验证和保存的。验
: 证比计算要简单。
:
: app
: server
|
T*******x
发帖数: 8565 | 23 请教一下：mvc里的m不是应该算后端吗？
【在 g*****g 的大作中提到】
: 商业逻辑是不能放进前端的，无关安全的商业逻辑，又不需要多客户端或者不怕重复代
: 码，
: 你写进前端是可以实现的，但仍然不是什么好的做法。单页面web app +html5 local
: storage，
: 无非是server mvc改成了client mvc，整个mvc都是前端，有区别吗？
|
g*****g
发帖数: 34805 | 24 m 只是presentation和service交换的对象。有个名词叫做 data transfer object. m
是无逻辑的。
【在 T*******x 的大作中提到】
: 请教一下：mvc里的m不是应该算后端吗？
|
