另一方面，锚文本能作为对所指向页面的评估。锚文本能精确的描述所指向页面的内容，个人网站上增加Google的链接，锚文本为 “搜索引擎”。这样通过锚文本本身就能知道，Google是搜索引擎。
那么在单页面里的功能切换时候我们改变一下url上的锚文字，反过来说使用锚文字做路由器，让其可以路由到对应的功能页面那么上面的问题不就可以解决了。关于锚链接我这里要补充一些知识，首先锚链接的形式是url#文字，锚的起始标记是#号，这个#号的内容其实是属于浏览器端的，也就是说#包括#号后面的内容是不会被发送到服务端的，那么我们想改变锚链接只能在客户端进行，但是传统的锚链接的变化是很难被javascript语言监控到的，直到html5的出现才从根本上解决了这个问题，html5提供了hashchange事件，该事件可以监控锚链接的变化，因为javascript语言可以监控锚链接的变化，那么使用锚链接路由功能页面就成为了可能，那么低版本的浏览器该怎么办了？这个主要是ie的问题了，其实ie8包括ie8都支持hashchange事件，再低就不行了，不过jQuery有个插件可以让低版本的ie支持hashchange事件，有兴趣的童鞋可以百度下啊。
看来泼凉水二问题是有解的，那么泼凉水一怎么解决了？我的回答是基本无解，这个问题的关键在网络爬虫这边，如果我们被动解决这个问题，那只能是抛弃javascript了，这个玩笑就开大了，所以我们只好祈求各大搜索引擎能不能智能化再厉害点了。这里加个题外话，我最近几天突然意识到一个问题，那就是讲到web前端技术我一定要加强对SEO的思考，因为绝大多数网站都会把搜素引擎当做入口的生命线，这是一个很难回避的问题，不管我们网站做的如何优秀，假如用户很难找到它，那一切都将会是百搭，而在前端设计里要加入SEO的思考，这必然会导致整个架构的重大变化。这个问题我会在以网站静态化角度审视前后端分离方案时候重点讲下。
前端MVC讨论到这里我们会发现我们的谈论里缺了一环那就是MVC的M层模型层，web前端要侵入到模型层了，这不就等于web前端要造反了，它不仅仅想改变从属服务端的悲惨命运，还要抢夺服务端的部分功能，让服务端成为浏览器对应的存储系统，这不是无异于虎口夺食，在时下服务端如此强势的大环境下，这种想法简直就是活得不耐烦了，哈哈，当然这是戏言了，做技术做工程还是要讲求个合理性和逻辑性的，技术和工程都是实在的东西很讲道理的，只要道理站得住脚怎么个做法都是其次，回到问题本身，我个人觉得在PC端讨论web前端做模型层其实往往利大于弊，就安全而言，模型层意味有大量业务逻辑推移到web前端，那么安全的保障难度会加大，就技术难度而言，web前端做模型层会让javascript编程巨复杂，所以要做这个抉择时候一定要结合业务做仔细的权衡，其实我现在接触的一些说包含模型层能力的前端框架在实际运用里模型层的功能还是使用太少，不过这个问题如果放到移动端，或者是PC和移动端融合可能就会有些不同，这个问题我将在本系列的终篇里再谈谈，这里也不累述了。
说到这里需要总结下了，前端的MVC不应该等于单页面开发，前端MVC也不是把ajajx用到极致，根据实际业务场景，我们需要适当的把同步请求和异步请求结合起来。如果前端MVC里包含了更多同步请求，那么对于MVC里的C层即控制层就会有更高的要求。前后端分离主题还有个下篇，下篇里我还会提到一种前后端分离方案那就是nodejs的运用，而nodejs的运用就是和控制层有密切的关系，上篇里我提到nodejs是前后端分离方案的催化剂，其实我个人认为nodejs参入的前后端分离方案才是更加完美些的前后端分离方案，这个完美的评价原因之一就是从前端承担控制层作用角度思考的，所以前端控制层这个内容我将放在下篇讨论。
好了，本篇写完了，从本篇我们可以看到前端MVC的历史很早，它的出现早于nodejs,这就说明前端MVC其实并不是什么新技术，只不过是现在才被大家重视起来，完善它的人也越来越多。从本篇我们还发现前端MVC其实并不完美，问题很多，最致命的就是对网络爬虫的不友好，所以我们需要考虑到SEO技术参入其中的前后端分离方案。
最后，祝大家晚安了。
">
×