超越起点 追随自由 我想故我所有

我看不见,我的明天,但今天,绝不重复昨天;顺风是滑翔,逆风才是飞翔,火烧过才能化凤凰!总想对你表白,我的心情是多么豪迈
总想对你倾诉,我对生活是多么热爱

  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  150 随笔 :: 18 文章 :: 2052 评论 :: 30 引用

连接
◆《重构之美》总目录
上一篇:重构之美-跨越Web标准,触碰语义网[开门见山:Microformat] (8-11 00:28)
下一篇:重构之美-跨越Web标准,触碰语义网[分离:通用也许是个美丽陷阱] (9-23 08:43)


分离,这个美丽的词,自从Web标准出现后,便梦萦魂牵的围绕着我,吞噬着我的脑细胞,一百遍啊一百遍。

《理解表现与结构相分离》,多么古老的文章;分离,多么诱人的词语!作为Web标准的核心理念,理论上是那么的干净,透彻与清晰,可为何放到实际操作中却那么的棘手和困难?直到四年后的今天,我仍挣扎于其中。

我第一次真正以团队角度去尝试分离是06年《重构之美》发表完后,我开始以结构化的理念去实施。结果是我基本成功的分离了原本纠缠在一起的前端和后端,但是在前端却没有完成分离,甚至一度我成为了团队的一个瓶颈,因为虽然我解放了后端,却没能让解放出来的大量工作协调的分配给前端的每个人,我只能一个人扛着,我分不出去,06年下半年,我几乎天天0点离开公司,每天12到14小时的工作。那时廷廷对我反复说的两个字是:放下!叫我不要把所有的事都揽到自己手上,哪有下属准点下班双休,而主管天天熬夜还包括周末的。我一脸沮丧的望着他:我分不出去……放下的前提是拿起,我没有拿起,我就没有资格放下,我也放不下。所以我必须先奋力去拿起。

前端和后端的分离相对而言是最容易的,只要后端放弃对结构的编写即可做到,其实在这最容易的一点分离上我也走了一年的弯路。通常而言,一个大团队,后端的人数远远高于前端,不少公司在前端的定义上仅仅限于界面设计,而交互、结构甚至样式其实都放在了后端上,由程序员完成。因此我曾理想的希望每个程序员都能够熟悉Web标准的理念,能够统一思想写出标准化甚至相同的结构,这样可以将结构的编写由众多程序员来平均分担,避免压力全部集中在前端。但是半年多的几次尝试过后我放弃了,首先编写一份合理的结构所需要的附加能力,都是程序员不应该投入精力的前端工作,其次结构的编写是个仁者见仁、智者见智的工作,想统一每个人的思想,何其难!而当我放弃后,当程序员不再参与对结构的编写后,前端和后端的工作就清晰的分离了。这里要特别强调,后端放弃对结构的编写是指每一个标签的确定都不参与。这对一些控件形式开发是个打击,比如asp.net的一些控件,如果前端确定的结构是“<div>数据</div>”,后端这么操作“<div><asp:label /></div>”那么就错了,因为最终输出的是“<div><span>数据</span></div>”。

博客园里大部分都是程序员,实际上普遍来说,程序员也远远高于设计师,看我的文章很多都是程序员,听到我说放弃对结构的设计也许会有抵触,尤其是一些不错的程序员。我想一些工作了三、五年的程序员在前端上的造诣或许不亚于甚至高于工作了一、两年的设计师,即便这样,我建议你要做得最好是指导而不是代替。其实真正优秀的程序员会很准确的找到自己的位置,会很清楚自己的光芒在哪里或将在哪里才是最耀眼的。

说到这里我突然想到也许会产生一个混淆,然后特意去百度“Web标准 程序员”,出现一篇广为传播的文章《网站程序员如何应对web标准》。然后我再次发现不可思议的文章:《为什么ASP.NET程序员应该学习Web标准》,好像还是翻译的,国外的文章。

在第一篇文章中,举了一个例:

<asp:Repeater ID="topNewsList" runat="server" >
  <HeaderTemplate>
  <ul>
  </HeaderTemplate>
  <ItemTemplate>
  <li><a href="shownews.asp?id=<%#Container.DataItem("id")%>"><%#Container.DataItem("title")%></a></li>
  </ItemTemplate>
  <FooterTemplate>
  </ul>
  </FooterTemplate>
</asp:Repeater>

它说这部分代码,由“页面设计师”也就是表示层的程序员完成,这实际上是程序员参与了结构的设计,确定了ul、li、a,我觉得这是错误,而且从某种意义上来说很严重。首先必须区分一下,程序员和设计师的界限在哪里?前端也有编程开发一说,那么和后端的编程开发区分在哪里?再宏观点,什么是前端?什么是后端?这条三八线应该怎么划?

什么是程序员?数据层的开发是程序员,还有通用层,业务逻辑层,表示层。表示层算不算程序员?算前端还是后端?js随着ajax新生,也会和数据频繁打交道,交互开发是不是程序员?又算前端还是后端?写代码的开发就是程序员吗?程序员就代表后端吗?那么结构的设计也是写代码,样式的设计也是写代码,都算程序员都算后端罗?除了界面设计,都是开发都是程序员都是后端罗?最搞笑的是很多人不说自己在做样式设计、交互设计而要说成样式开发、交互开发,甚至还有结构开发,我琢磨着剩下孤零零的界面设计,哪天不爽了跳出来高呼一声“还有我界面开发”,似乎顶着“开发”二字,脚不弯了,腰也直了,鸡胸也挺起来了……凸-.-凸

实际上设计师、程序员、设计、开发都是文字忽悠游戏,无所谓。但是前端和后端是应该有分界线的,而这条三八线,我认为:以操作方式来划分。凡是不需要环境可以静态完成设计、开发与调试的工作是前端。而需要运行环境、编译、数据库等必须动态化才能完成设计、开发与调试的工作是后端。所以大部分交互开发虽然也是编程也会操作数据库,但是我认为它还是属于前端,而表示层的开发则属于后端。“程序员”这三个字通常更多的是泛指后端。那么在上面的实例中,就应该这样:由前端确定用ul还是ol还是div等,后端要做的是动态化页面(加入数据并循环)。用什么方式实现数据的载入(Repeater控件还是其他)不关前端的事,而用什么结构标签格式化数据不关后端的事!不要说后端了,这甚至不关位于前端的交互开发的事,交互开发无论从协同考虑上、性能考虑上、维护考虑上都需要尽可能的避免创建结构,更不应该擅自创建结构。

上面两篇以及类似的一些文章,我认为最大的错误就是没有立足于团队的角度去明确区分前端和后端,混为一谈。简单说说在这点上我的经历和态度转变:2006年上半年我对方欣几十个程序员做Web标准培训,那时我是完全希望结构由程序员编写,结果完败;2006年下半年我在卡当,我再次提出全体培训,被拒绝后开始以边开发边沟通的方式将Web标准理念分散渗透和传递,那时我虽然仍抱希望,却已经有所怀疑,因为我发现结构本来是简单的东西,但是一旦多人带着仁者见仁智者见智的心态去操作时,它就变得复杂难控,于是我开始抓结构的决定权,结果成功了;2007年在爆米花,我开始常说一句话:“不管你用什么方式,控件或编程或其他我听不懂的,反正我只要最终输出的页面,在浏览器中查看源代码,其结构和前端确定下来的完全保持一致,丝毫不差,就OK,剩下的事属于前端,你可以不管了。”程序员可以建议或提出障碍,但是结构的决定权100%的落在前端,我完全的放弃了对程序员的主动培训,结果轻松而极速。

那么,程序员是否需要学习Web标准呢?这个问题换个角度,就是问:设计师需要学习数据库吗?答案其实是一样的:需要。但是这种学习我觉得应该是属于了解的学习,而不是钻研,是辅助的学习,而不是主导。为什么?因为首先确定结构需要深厚的CSS设计能力作为支持。两年前我写过一篇《CSS,Stop!》的文章来提醒大家关注结构,很快我就想再写一篇《CSS, Important!》的文章来阐述结构和样式的关系,因为通过后来那道面试题我发现,CSS的设计能力在很大程度上影响和限制着你的结构设计能力,如果你CSS水平不够你根本不敢去选择更好的结构哪怕你知道(比如你如果不知道如何清除浮动,势必要加入冗余标签)。其次,CSS和界面设计又是密切相关的(比如圆角的变通灵活实现或图片切割的针对性设计),和交互设计也有瓜葛,而最后界面设计与交互设计源于产品设计。这条线就牵出了前端两个字。如果程序员编写结构,就要学习CSS,然后被莫名其妙稀奇古怪的浏览器兼容打懵掉,还得纠缠进界面艺术及排版设计……一步一坑,越走越不熟悉障碍也就越大,水深火热,最后导致的结果便是团队无法形成专业的前端队伍,也无法形成专业的后端队伍,人人在执行上身兼数职,单兵作战,更不要说协同了。这无论对团队还是对个人都是糟糕的:团队是混乱的散沙,个人是平庸的全面。

程序员可以学习Web标准,如果自我感觉很好,可以建议甚至强烈建议,但是不要去替代去操作。术业专攻,博览群晓。前一句指在执行上专一,后一句指在认知上全面。其实我认为如果你决心投身于后端做个牛逼的程序员,完全可以不用在实践中去刻意学习Web标准,学习方式很多,沟通协同中也能学习和了解很多,足矣。而执行上的做与不做,对于个人没影响,一个人可以从头做到尾,但是对于团队这个问题很重要,非常重要!你必须认识到一点,全能是幻象,没有在执行上既精于前端也精于后端的人,因为时间和精力是有限的,你必须放弃,让自己有短处,你才可能拥有傲人的长处。当然我知道还有客观环境在左右程序员的行为,是公司没有建立前端队伍而导致程序员不得不去扛起前端的工作,这是很无奈的事情。所以众多网站强在后端弱在前端,怎么可能不弱嘛,前端的工作由后端程序员兼任,想起一句话:“抢劫,咱不专业啊。”再说下去就是前后人才问题了,不说了。

差不多说完了,我想有人会说:“你在说大团队,我们是小团队人少,不可能分得那么细。”其实无论3、5个人的小队还是30、50个人的大队都可以并应该把前后端分离开来。这个东西,和人多人少没关系,人少你都分不清,人多了就只会更混乱。

所以,分离的第一步:程序员们,珍爱生命,“远离”标准;CTO们,珍爱程序员,分离前后端。


连接
◆《重构之美》总目录
上一篇:重构之美-跨越Web标准,触碰语义网[开门见山:Microformat] (8-11 00:28)
下一篇:重构之美-跨越Web标准,触碰语义网[分离:通用也许是个美丽陷阱] (9-23 08:43)

posted on 2008-08-20 00:06 爆牙齿 阅读(3772) 评论(50) 编辑 收藏

评论

#1楼 2008-08-20 00:19 阿叔      
深有体会!支持,虽然我只是一个小小的程序员!
 回复 引用 查看   

#2楼 2008-08-20 00:24 水言木      
沙发,好文!
 回复 引用 查看   

#3楼 2008-08-20 00:41 重典      
文章很好。
 回复 引用 查看   

#4楼 2008-08-20 01:14 梁逸晨      
楼主说的,正是和我打了几年冤家的东西,深有体会。

目前我的解决方案:

程序员负责生成和输出XML文档,由设计师来完成XSLT。这样就做到了完全的分离。我认为这个现成的解决方案是很不错的。

主要是由浏览器来完成这个转化过程,但是服务器端的转换功能也保留,这样就可以在某些场合下输出HTML。
 回复 引用 查看   

#5楼[楼主] 2008-08-20 01:22 爆牙齿      
@梁逸晨
我个人不喜欢XML+XSLT的解决方案,也曾经讨论过。
我认为:
1、转换会有性能损耗。
2、比原有的在流程上多出一步来。
3、html已经搞大头了,XSLT对主要工作非编程的设计师来说,无谓的又增加一道技术障碍且不低,不仅仅是要学习XSLT,还要学习XML,这将带来新的学习成本和人力成本。
 回复 引用 查看   

#6楼 2008-08-20 05:03 怪怪      
好文, 正是我要解决的。 其实我快大半年前提到的框架, 其中一部分正是用来解决这个问题的; 经过我这半年的思考,我认为完全可以做到后端完全不管任何HTML且前端完全不用知晓任何后端的工作, 同时将循环和控制的代码也好控件也好彻底从html中剥离。

不过我没有合适的、 真正懂行且具有自己感触和体会的高手一起交流, 无法印证想法,唉可惜你又没时间听听我的做法 :(。

我虽然具体技巧非常差(比如长期用恶心的<div style='clear:both;' />来清除浮动,这个应该怎么做?), 但是基本你说的我都认同; 只有真正分离才能让所有人求得解脱,较劲是成功不了的。 我想我是一个程序员, 我应该有这个责任解放别人的工作, 而且不要脸的说我也初步具有这个能力,所以到现在还是跃跃欲试。


我现在的障碍, 除了得不到你这样的家伙的帮助, 另外就是心里有一个疑惑, HTML/XHTML到底还有多长的生命周期?我个人认为鉴于当前互联网存在的文档形式所造成的浏览习惯, 应该不会很快被取代, 但是仍然心里没底, 不知你如何看待这个问题?
 回复 引用 查看   

#7楼[楼主] 2008-08-20 07:30 爆牙齿      
@怪怪
首先,这个问题的解决很简单,我文中已经说了,结构由前端确定每一个标签,就行了,通俗点:前端给出html,后端套上程序或输出这样的html,前后就分离了,前端不管后端的表示、逻辑、通用、数据等各层,后端不管html、css、js和界面设计,依葫芦画瓢输出就行。

其次,你说到了“印证想法”这四个字。印证想法不是通过交流也不是通过思考,只有实践,实践才是检验真理的唯一方法。想到和做到天壤之别,而且从想到到做到这个过程非常有价值,梦想要照进了现实才有意义。照照照,很多时候我苦恼的不是想不到,而是做不到,而做不到更多时候不在能力上而在环境上。所以细节很重要,尤其在行为上,决定了你做不做得到。不要跃跃欲试,亲历亲为马上去照一下,只有做到了才能说具备了某一点的能力,现实很复杂,只是想到,就还太远。所以这个世界永远不缺想法和点子,缺执行力。哎呀,不和你说了,再说我以后的文章没东西可忽悠人了。

最后,清除浮动,百度专业,我不专业。Web标准的生命力和浏览器绑定,甚至生生不息,体消魂在。

 回复 引用 查看   

不知道lz要分离什么?

我觉得前台就是显示数据的,后台就是提供数据的。

这样看就很好分离了,但是有一点不好分离,那就是循环。

比如一个新闻列表,要显示多条新闻,那么就要用for循环来做,或者用repeater、Datalist等。总之要循环一下,就是这个循环需要在前台来做,lz不会是想把这个也放在后台吧。

对于程序员来说,循环放在前台是很简单的事情,但是对于美工来说就麻烦了。
 回复 引用 查看   

我任职于一家小公司。美工完成效果图,并切片把效果(HTML)的发给我,剩下都自己搞定。哎
 回复 引用   

#10楼 2008-08-20 08:30 NormRen[未注册用户]
写的好,这个前端结构就应该是一个理解了语义化结构的页面设计师指定的。清除浮动确实需要“技术”啊,到现在我都没法摆脱引入<div style="clear:both"></div>
 回复 引用   

#11楼 2008-08-20 08:36 韩现龙      
好文,不想就此问题发表什么看法.
 回复 引用 查看   

#12楼 2008-08-20 08:36 菜菜灰      
表现与结构应该在拆分开来,分为表现,结构和数据分离。而web标准真正的分离是指表现,结构和行为的分离,这点很重要。
 回复 引用 查看   

#13楼 2008-08-20 08:38 雅阁布      
好文章!!
学习!!
 回复 引用 查看   

#14楼 2008-08-20 08:40 Q.Lee.lulu      
又见暴牙兄的好文!!
 回复 引用 查看   

#15楼 2008-08-20 08:41 怪怪      
@爆牙齿
呵呵, 还吊胃口 :)

我知道你的做法, 但是我觉得“后端套上程序或输出这样的html”这样分离的还不够, 也许是我太较真了?总而言之我的想法是, 后端应该只提供他负责的部分(依赖服务器的行为、数据), 甚至是不是用于组织html都无需操心, 这根本与他无关。

而前端呢, 做好那种“静态示例页面”就可以了,任何一个和后端相关的字母都不必要,也不依赖于后端输出任何一个除数据以外的字符, 干净到这种程度,不同的角色之间就不用操心对方如何做了,而且是靠系统的强制性而不是人来保证这些。

说白了, 这中间肯定需要一个胶合层, 关键是把握好这个层的设计, 它不能限制前端、后端的发挥, 同时在使用上不能过于“强大”和“厚重”, 变成了另一个侵入式框架。

我对环境其实抱有乐观态度。 我可以选择不接受我的方案的, 不合作, 无论是客户、伙伴还是其他什么; 只要这种改善能降低复杂性、提高生产效率达到一定程度, 我相信还是能找到愿意接受他们的各种不同角色的人。

我真正的问题确实如你所说, 是执行力和细节的问题; 所幸具体到这个课题,其实是我心里最有谱的一个: 初步的可行性的原型和在.NET平台上所需的相关技术全都已经验证过了; 这其实正是多个我感兴趣的领域里, 这个课题吸引我想去最终把它完成的理由之一。

说到未来走势的影响,主要是这个计划如果以配套完整的开源产品为目标,其开发周期会比较长; 要是到时候满眼RIA了, 不是说这种方式不能用在新的RIA上, 但价值就小很多, 不值得一做了: 体消魂在是肯定的, 但场景一变,待解决问题的优先级列表就变了。

另外说实话到最后, 我发现根本没必要使用.NET, 因为我借助它的支持的地方并不多,相反要克服.NET本身框架带来的麻烦。 这样我又想另起炉灶, 却又有一些其它心理活动(比如那样得自己开发IDE插件,而这个工作是我没有评估过的), 这个方面的多种因素导致下不了决定。

这确实是我自己的问题, 在你这里唠唠叨叨, 见笑了 :)。
 回复 引用 查看   

#16楼 2008-08-20 09:04 小狼壮壮      
我现在在项目中使用 Nvelocity模板引擎,将后端获得的的数据(变量,数组,泛型等等)统一装载成模板中的标签。 模板是嵌有标签的纯html。我认为目前是实现了前端与后端的完全分离,还没有发现什么不妥之处。
 回复 引用 查看   

#17楼 2008-08-20 09:11 XeonWell      
暴牙兄写的很深刻, 学习了.
 回复 引用 查看   

#18楼 2008-08-20 09:21 赵俊      
--引用--------------------------------------------------
elaner.ifso: 我任职于一家小公司。美工完成效果图,并切片把效果(HTML)的发给我,剩下都自己搞定。哎
--------------------------------------------------------
好像大多数“小公司”都是这样做的,有些大公司甚至前段只负责画界面图,连html都没有。
 回复 引用 查看   

#19楼 2008-08-20 09:21 airwolf2026      
“抢劫,咱不专业啊。”
 回复 引用 查看   

#20楼 2008-08-20 09:27 迷惘[未注册用户]
对于小开发团队和小项目,这个划分标准好像不太科学,因为小项目前端的工作量远远比后端多。而小团队缺乏专业的界面设计人员。我看到的大多是连html都不会,只会画画的美工。
 回复 引用   

#21楼 2008-08-20 09:42 戏水      
分离 是指什么的分离呢? 是数据和表现的分离。 我觉得这个不可能绝对分离,再快的刀也只能切出个藕断丝连来。
逻辑 可以分为 业务逻辑和展现逻辑。这两者往往你中有我,我中有你,是最难分离的。讨论这个话题最好是举个具体的情景出来。
 回复 引用 查看   

哈哈,认真看过文章的人,我想很快就明白自己曾经做过的一些列事。
3、5个人的分离是可行的,可怕的是3、5个人不到!我都不知道还会在这3、5个人不到的“团队”中逗留多久,累了,真想休息!
 回复 引用   

#23楼 2008-08-20 09:57 xiao_p      
前后分离,我感觉更应该加强素质的是美工和设计师,而不是程序员。

没有夸奖程序员的意思,但是相对于大多数美工来说,程序员在理解逻辑性上的事物来说,要快的多。

几天前,找到单位的美工,想帮忙调下css,因为firefox下有点变形,对于大多数美工来说,这应该不是什么大问题吧,毕竟只有css,还只是局部略微变形,其它的 我都自己搞定了。

结果,告诉我 电脑上没有firefox,不能帮忙,我当时就晕了。
这就是一个专做html的美工,更郁闷的是后面,问我,为什么要用div,不用table?。。。。。。。。。。。。。。。。。。。。。。。。

table布局???

这样的美工还希望前后分离?。。。。。。。。。

呵呵,在lz这 倒倒苦水,实在是有点不爽!

感觉 现在大多数的美工的素质还真不是一般的差!!!
 回复 引用 查看   

#24楼 2008-08-20 09:58 Tony Zhou      
自己写控件咯?
 回复 引用 查看   

#25楼 2008-08-20 10:01 阿一(杨正祎)      
踩一脚。

给个我的思路:
方法一:
如果是后期更新或者修改较少的项目:后台程序员把数据直接扔到页面上,不要讲究版式和样式。最多用个hr隔开一个。然后前台把这些装满的控件的页面修整一个。——当然,要求前台了解必要的程序,至少你要知道label到了前台是span。

方法二:
前台也好静态页面,后台程序员,用控件替换静态页面的标签。当然要去后台了解一些前台的知识。

方法三:
对一些需要持续更新、样式简洁的网站。前台多模板、规范化、制度化。后台只要套模板,使用那些样式就可以直接作出简洁的页面,然后前台再稍作优化。

个人拙见,切勿见笑。
 回复 引用 查看   

#26楼 2008-08-20 10:11 Bao      
之所以分不出来还是因为现在程序员还要关心页面的样子
 回复 引用 查看   

我有个想法是不是我们把顺序搞反了?我想是不是先由程序员生成一个空白的,完全没样式的页面,把页面需要的数据全部堆上去,然后再让美工去以这个为基础做页面,呵呵,临时这么想了想
 回复 引用 查看   

#28楼 2008-08-20 10:18 Sam Lin      
在小公司就不太适合了,会增加公司的成本,很多几个员工的公司都是没有美工的,程序员一手全揽,一身多职
 回复 引用 查看   

#29楼[楼主] 2008-08-20 10:22 爆牙齿      
看了这么多朋友的回复,我只有一句:
如果我在你们的公司里,你们公司铁定会被我上蹦下窜搞得乌烟瘴气,闹翻天。

哈哈哈哈哈
 回复 引用 查看   

#30楼 2008-08-20 10:23 datasky      
 回复 引用 查看   

#31楼 2008-08-20 10:55 Jeffrey Zhao      
程序员不该确定tag的确说的没错,但是前端设计师使用Repeater,ListView这种不会生成多余html的控件很好用,还是推荐用的。
 回复 引用 查看   

#32楼 2008-08-20 10:57 小狼壮壮      
嗯 同意赵老师说de
 回复 引用 查看   

#33楼 2008-08-20 11:14 nebel      
好文,先顶下。

 回复 引用 查看   

#34楼 2008-08-20 11:16 Tony Zhou      
这样一来很多.net自带控件就不能用了,都要自己写?
 回复 引用 查看   

#35楼 2008-08-20 11:28 Jeffrey Zhao      
@Tony Zhou
的确
 回复 引用 查看   

#36楼 2008-08-20 11:37 css design      
那JS代码,比如效果菜单,广告代码等是前还是后呢
 回复 引用 查看   

#37楼 2008-08-20 11:57 westup      
希望还能有一篇针对美工(html,css,ps)的文章~很多ajax,js需要我们来写吗,俺们不会编程,拿来用还是可以的~
 回复 引用 查看   

#38楼[楼主] 2008-08-20 12:47 爆牙齿      
@Jeffrey Zhao
没认真看文章,仔细想想我对前后端界限的划分方式,我还加了粗的,这很重要……

我觉得使用Repeater之类的控件是属于后端表示层的开发,根本和前端无关,所以这部分工作不该由你说的“前端设计师”来学习、使用和完成。而做这部分工作的人属于程序员,学习方向应该是更深的数据库方向,而不是前端方向。

你想,如果一个真正的前端设计师学习的.Net的Repeater表示层开发,那么他到java团队中怎么办?php呢?前端应该是通行的,主知识范围也应该这样。而且我说了静态开发,作为前端,我甚至不需要学和用.Net庞大的VS,或者JAVA的Eclipse,也不需要数据库不需要开发环境,FW或PS、文本编辑器再加上用于调试的各种浏览器就可以通行并高效的完成工作。

作为一个前端设计师,他可以了解.Net下的数据循环方式,可以了解JAVA下数据循环方式……但是没必要去操作和执行,因为不是前端的主知识面,前端主攻面是UI和UE的学习与设计再上到用户需求的处理,而不是数据的处理。用Repeater,我需要知道Container是啥?DataItem是啥?好吧,复制即可,那么“title”变量名从哪里来?谁提供?我还需要安装VS,学习使用,还要配置运行环境连接数据库,数据出不来我找谁?我还要学习断点调试吗?一层层深入进去,会像程序员操作css类似的一步一步陷进数据库的泥潭中。优秀设计师就这样变成半吊子程序员了。

前后分离最纠缠的就是这个环节。各种编程环境下逃不掉写类“Repeater”控件这个工作环节,那么该由前端完成还是后端完成,我通篇文章写的就是这个!阐述前后端的分界线,这和后端里面的前后台开发是不同的。后端的前台开发是指表示层的程序开发。而我说的前端完全不是表示层的程序开发。

我觉得我文章说清楚了呀,发之前反复斟酌和修正了十多遍,完全是用写书的姿态来写博,唉……
 回复 引用 查看   

#39楼 2008-08-20 13:33 igaofen      
可以用模板引擎或mvc来完成分离,后台只提供数据就可以了.
 回复 引用 查看   

#40楼 2008-08-20 13:35 igaofen      
程序员提供一个提供数据的说明 让UI开发人员用标签来使用数据,以后改版就不要改程序了,前台决定怎么使用数据,不是后台决定怎么输出数据
 回复 引用 查看   

#41楼 2008-08-20 14:38 Tony Zhou      
--引用--------------------------------------------------
igaofen: 可以用模板引擎或mvc来完成分离,后台只提供数据就可以了.
--------------------------------------------------------
同意,楼主的情况不需要用控件了。
 回复 引用 查看   

#42楼 2008-08-20 14:43 cipchk      
其实就像说的"依葫芦画瓢输出",我认为中间还是需要一层保障的(并非不相信程序员),还是说后端人员根据前端提供的“样例”直接输出然后由程序员运行试试生成的XHTML代码是不是一样结构。再假设一个问题如果说前端开发人员在a标签中少了title,这时后端人员能发现吗?(我并非完美主义者只是说明问题)

而且大家讨论的都是在开发阶段,而对后期的维护、需求的变动,这时还需要前端、后端的合作,由前端人员先做样例,由后端人员负责输出?
 回复 引用 查看   

#43楼 2008-08-20 15:21 随风流月      
整个项目只有一个人, 怎么办?
 回复 引用 查看   

一个优秀的应用设计师,要求他对数据结构的了解是非常重要的。

再让我们看看来自程序员社区的一些声音:

[quote]mobilefeather 写道
[quote]个人理解,B/S模式就是C/S模式的特例,只是将客户端放在了浏览器里。可是现在的开发模式就非要把本该在客户端做的事情放到服务器里做,导致开发异常复杂混乱。我经常在跟同事讨论问题的时候,发现有人会搞不清楚一段代码到底是在服务器执行还是在浏览器执行。因为现在的框架完全模糊化了这些概念。

我是从做DELPHI转过来做JAVA WEB开发的。我总有个想法,就是重视起浏览器端的JS开发,将其定位成WEB的客户端开发。最终实现一个类似VCL的界面组件框架,和类似DELPHI的可视化IDE,这样才能简化WEB界面的开发,提高效率。浏览器客户端与服务器端通过HTTP协议承载两者交互通信,再上层可以用XML封装复杂数据。这样才能将服务器与客户端开发解藕,达到分工明确,降低开发难度,提高效率的目的。否则以目前的开发方式,不管用什么STRUCT、JSF,都只会更增加复杂性,WEB开发的效率永远都不可能超过C/S的。[/quote]

你可真敢说,我有这样的想法,可我就不敢说,
因为我讨厌对立的争论,对立的争论没有任何价值,
你敢,不过我建议你,如果别人反对你的观点的话,不要和他们争论,99%你是说服不了别人的,那不就是浪费生命,
我们连自己都救不了,别人就不要管了,
还有就是,既然我们在B/S要分离这上面有共识,
那我说说我在实战中的感受。
首先,这个观点的产生是实践的来的,虽然我做web开发只有2年时间,可是我的程序年龄已经13年了,
这13年中当然也不是一直在做程序,也荒废了几年,不过我一直都把自己当作是程序员的,就算荒废的几年也一直在学习。
自吹一下,有13年程序年龄的人,产生出一些观点,应该不是空穴来风吧。
在这两年的web开发中其实我有1年时间做的是服务器端的插件和内容的负载均衡的工作,页面上的事情这1年当中我没有做,以至于最开始做页面的时候,我认为很简单的东西,最初要做的是一个简单的论坛,我就想当然的认为,这么简单的需求,比起我原来用delphi做的帐务管理系统来说太简单了,只需要1周就可以完成,可事实是我用1天的时间规划建立了数据库结构,数据结构有了其实最基础的业务逻辑也就出来了,细节是实现时候处理的。可剩下的6天困死在页面上了。
当然造成这个局面的原因就是我低估了页面的复杂度。这个项目自然就流产了。
再后来的1年多里,我下功夫的学习了web的开发,html,DOM,css,javascript,结果就是我发现:
[color=red]web开发实际上重头的工作在表现上,真正后台的代码很少,可以说,后台很多有难度的代码都是为表现做的,
为什么不能吧前台的活交给前台去做?后台的活交给后台去做?[/color]
现在有这样的工具比如前面有朋友说的GWT,
可是我仍然不赞同这种观点,为什么不构造一个纯前台的GWT要做的工作呢(仅指前台部分)?
也许有人说:
不要重复造轮子==========开玩笑,程序员的工作就是不停的造不同的轮子,这样我们才能进步,当然策略还是要讲的,我相信不要重复造轮子这句话现在是被误用了。
搜索引擎支持问题怎么办======遇到问题就解决嘛,不要退缩,这不是程序员的工作态度,有问题我们要积极的解决他,就算现在没有完整的方案,这也不能作为我们前进的绊脚石。问题我们总能解决

……(code)

[b]在实际的项目中,我们的小组已经用这种方法工作了,效果很好,而且越发发现工作的重头仍然是页面。后台代码简单的一塌糊涂。简直就是随便来个程序员都能做。
一句话,我对B/S的分离很有信心,而且是B就是B,和S的耦合可以降到最低。 [/b]


再看看这篇:http://www.javaeye.com/topic/185839?page=1


PS :yahoo有超过800人的前端团队,而且仍旧有80%的问题是在前端。
 回复 引用   

#45楼 2008-08-20 20:06 阿鹏      
不管你用什么方式,控件或编程或其他我听不懂的,反正我只要最终输出的页面,在浏览器中查看源代码,其结构和前端确定下来的完全保持一致,丝毫不差,就OK,剩下的事属于前端,你可以不管了

很喜欢楼主的这句话,由于自己在学习中,使用div+css 和 .net 来建站.
可是做好静态的html后.使用.net编写成动态的.很多时候会被控件输出的标签变的不一致了.很困扰.我多么想和sina,163等那些大型网站一样,点击浏览器的查看,源代码,html代码是那么的漂亮.
最终不得以的办法,基本上是使用Repeter,DataList.因为舍不是控件.
更极端的做法,我想使用 foreach(Product p in products)这种形式来遍历把html代码耦合进去.

想让前后端的开发,最终代码一致,为什么就这么难,为什么163那些大网站就能做到.如果用.net开发,难道它们就不用控件.疑惑中........疑惑中......
希望楼主或牛牛们也给些意见,我是小菜...
 回复 引用 查看   

#46楼 2008-08-21 00:40 nebel      

用dotnet控件开发,控件有固定的html输出结构,不可避免的会有一些冗余标签的。jsp,php大概不存在这类问题。或者dotnet不使用控件开发,直接用模板引擎来开发,可以没有冗余标签。
--------------------------------------
我以前做asp.net,现在专职做前端,后端现在是php程序员在做。
我选择前端的原因,有部分就是感觉前端的发展不受后端语言的限制,职业范围选择的空间会更大点。而且越来越感觉,发展的方向要向需求处理的决策阶层那方面发展,空间会更大。
-----------------------------------------------
读了原文和评论。来谈谈我个人的想法(不管正确与否,嘿:)

前后端的一个结合点就是如何将后端输出的数据填充到前端设计好的静态页面中的”数据填充点”上。
对于 单个数据实体,问题不大。对于数据实体集,这个有时就会牵扯到“显示逻辑”的问题。
“显示逻辑”需要结合前端给出的“标签的嵌套逻辑”考虑数据如何循环输出。lz所说的后端的“前端”做的就是数据的“显示逻辑”的工作。

比如
1.  一个页面会细化出头部,<body>之上的部分代码都在头部,许多的页面都共用这个头部,那么在不同的页面中,需要引入不同的页面的css。
这个就是一种牵扯“显示逻辑”。需要通过程序提取一些环境信息来判断头部动态引入哪一个css文件。


例2.一种多级分类的显示问题。这个应该是一个典型的需要考虑“显示逻辑”的问题。
前端可以给出这样一段静态代码段:
<ul>
  <li><h3>类A</h3>
     <ul>
        <li>子类a1</li>
        <li>子类a2</li>
     </ul>
  </li>
  <li><h3>类B</h3>
     <ul>
        <li>子类b1</li>
        <li>子类b2</li>
     </ul>
  </li>
</ul>

后端嵌套程序的时候,在考虑循环输出数据的同时还要考虑到标签的嵌套逻辑的问题,在写php代码的时候,就要考虑到什么时候引入子类的ul标签什么时候再将这个ul标签关闭。尤其是3级,4级,n级的分类显示中,这种显示逻辑,会使程序员感到烦恼,不熟悉或者不关心标准的后端程序员,就会输出不符合前端给出的静态的代码片段的xhtml结构,很可能在哪个地方忘记了输出关闭标记</ul>.
而这种显示的处理,都是由程序员做的,也应该是程序员做的。
lz文中所说,给出了确定的静态页面就是前端确定了标签的页面,前端希望后端的处理能保持这样的一种结构,作为前端,并不想干预后端采用什么样的方式来保证这样的结构不变的输出。
php是不是用控件的,所以直接会在xhtml代码中硬编程嵌入程序代码,来完成这样的输出。asp.net用控件可能会引入一些冗余的<span>代码的代码。Repeater控件是不含内设的xhtml代码结构的,想grid这些控件已经内置了xhtml代码结构,这些控件是不能保证按所需的xhtml结构代码输出的。除非重写控件的内部xhtml结构代码。
所以确保按前端确定的结构输出,就尽量不使用含有内置xhtml结构代码的控件。 

 回复 引用 查看   

#47楼 2008-08-21 01:10 nebel      
现在比较大的公司都会有ued这样的部门。
这样的部门的工作,大概会从产品设计一直做到前端静态页面的完成,然后交给后端程序进行数据输出的处理。

个人来想一下前后端协作。
我挺赞同 lz所说:前端要把握住“前端标签的决策权”,后端" 每一个标签的确定都不参与"

但如何做到这样,考虑不使用模板引擎,和使用模板引擎两种情况。
不使用模板引擎:
  前端做好静态页面,是确定了最终标签结构的页面,这些静态页面交给后端,不管后端采用什么样的方式输出,前端只有一个要求就是确保动态的页面完成后,在浏览器中查看源代码应该是与给出的静态页面的标签结构一样的。
    这种完成的嵌入程序代码后的动态页面,后期如果需要调整xhtml的结构代码,可能还是会将前端人员和后端程序员给揉合到一起去,因为前端人员一般对程序语言不熟悉,特别是那些经过后端处理的“显示逻辑”比较复杂的地方。要修改必须程序员协助。没有达到mvc的那种模型的分离。
使用模板引擎:
  asp.net模板有stringtemplate,nvelocity等等,php有smarty等等。
  个人觉得使用模板引擎可以比较好的达到前后端的分离。使用模板引擎的一个难点就是让前端人员学习这些模板引擎语言的使用。据说 国外的前端人员都是有程序员功底的转型的。
   如果前端人员能懂模板引擎语言,大概可以进一步将“显示逻辑”中遇到的那些标签嵌套结构的逻辑从程序员的工作中分离出来,可以达到彻底让程序员" 每一个标签的确定都不参与"。这样,程序员只管提供数据输出,与标签相关的,只由前端来做。当然这个过程中,前端和后端需要有密切的沟通。  

个人见解,继续关注大家的讨论。
 回复 引用 查看   

用 asp.net mvc 不就能做到输出任意指定的标签了吗?
但是这样也丧失了一些灵活些/封装性,而这些是 asp.net webform 的灵魂。
所以 web 标准的要求对一般网站是有用的,对管理软件开发则是没有必要的。
其实说到底一般网站的前端用什么语言做都差不多的。
不管是 asp.net mvc 还是 ruby on rails 又或者是 django 等等。
 回复 引用 查看   

我是做网页设计的,我们的团队就是这样子分工,我觉得很好,我可以控制所有有关界面显示的东西,免得程序加的东西错位啊,和效果图不符等等情况发生,而程序就不用为CSS和HTML以及各个浏览器的显示效果这些东西分神了。但是,页面制作的人和在页面上写程序的人的相互沟通很重要,像一些交互很复杂的页面,还是需要两个人商量沟通协同完成比较好。。
 回复 引用   

我觉得CSS,HTML,关于前端显示的部份,这个不用说肯定是前端的人应该负责的,但是一些交互效果很复杂的,需要用大量的JS+CSS来实现的,可能某些部份还牵扯到数据库的,我觉得就很难分清楚该谁来写,其实写JS对于一般的网页设计师来说,还是有点难的,最好是两个人互相沟通,页面制作的人尽可能多的了解实现方式,可以提出来自己想要达到的效果,以及一些实现方式的意见,JS部份应该有程序员来协助完成。
 回复 引用