ASP.NET MVC使用Bootstrap系列（1）——开始使用Bootstrap - 木宛城主

本邮件内容由第三方提供，如果您不想继续收到该邮件，可 点此退订 。

ASP.NET MVC使用Bootstrap系列（1）――开始使用Bootstrap - 木宛城主  阅读原文»

作为一名Web开发者而言，如果不借助任何前端框架，从零开始使用HTML和CSS来构建友好的页面是非常困难的。特别是对于Windows Form的开发者而言，更是难上加难。

正是由于这样的原因，Bootstrap诞生了。Twitter Bootstrap为开发者提供了丰富的CSS样式、组件、插件、响应式布局等。同时微软已经完全集成在ASP.NET MVC 模板中。

Bootstrap结构介绍

你可以通过http://getbootstrap.com.来下载最新版本的Bootstrap。

解压文件夹后，可以看到Bootstrap的文件分布结构如下，包含3个文件夹：

• css
• fonts
• js

css文件夹中包含了4个.css文件和2个.map文件。我们只需要将bootstrap.css文件包含到项目里这样就能将Bootstrap应用到我们的页面中了。bootstrap.min.css即为上述css的压缩版本。

.map文件不必包含到项目里，你可以将其忽略。这些文件被用来作为调试符号（类似于Visual Studio中的.pdb文件），最终能让开发人员在线编辑预处理文件。

Bootstrap使用Font Awesome（一个字体文件包含了所有的字形图标，只为Bootstrap设计）来显示不同的图标和符号，fonts文件夹包含了4类的不同格式的字体文件：

• Embedded OpenType (glyphicons-halflings-regular.eot)
• Scalable Vector Graphics (glyphicons-halflings-regular.svg)
• TrueType font (glyphicons-halflings-regular.ttf)
• Web Open Font Format (glyphicons-halflings-regular.woff)

建议将所有的字体文件包含在你的Web应用程序中，因为这能让你的站点在不同的浏览器中显示正确的字体。

EOT字体格式文件需要IE9及以上浏览器支持，TTF是传统的旧字体格式文件，WOFF是从TTF中压缩得到的字体格式文件。如果你只需要支持IE8之后的浏览器、iOS 4以上版本、同时支持Android，那么你只需要包含WOFF字体即可。

js文件夹包含了3个文件，所有的Bootstrap插件被包含在boostrap.js文件中，bootstrap.min.js即上述js的压缩版本，npm.js通过项目构建工具Grunt自动生成。

在引用boostrap.js文件之前，请确保你已经引用了JQuery库因为所有的Bootstrap插件需要JQuery。

在ASP.NET MVC 项目中添加Bootstrap文件

打开Visual Studio 2013，创建标准的ASP.NET MVC项目，默认情况下已经自动添加了Bootstrap的所有文件，如下所示：

说明微软对于Bootstrap是非常认可的，高度集成在Visual Studio中。

值得注意的是，在Scripts文件中添加了一个名为_references.js的文件，这是一个非常有用的功能，当我们在使用Bootstrap等一些前端库时，它可以帮助Visual Studio启用智能提示。

当然我们也可以创建一个空的ASP.NET MVC项目手动去添加这些依赖文件，正如下图所示这样，选择空的模板：

对于新创建的空白ASP.NET MVC项目来说，没用Content，Fonts，Scripts文件夹——我们必须手动去创建他们，如下所示：

当然，也可以用NugetWebRTC手记之初探 - 孤竹君  阅读原文»

WebRTC是HTML5支持的重要特性之一，有了它，不再需要借助音视频相关的客户端，直接通过浏览器的Web页面就可以实现音视频对聊功能。而且WebRTC项目是开源的，我们可以借助WebRTC源码快速构建自己的音视频对聊功能。无论是使用前端JS的WebRTC API接口，还是在WebRTC源码上构建自己的对聊框架，都需要遵循以下执行流程：

上述序列中，WebRTC并不提供Stun服务器和Signal服务器，服务器端需要自己实现。Stun服务器可以用google提供的实现stun协议的测试服务器（stun:stun.l.google.com:19302），Signal服务器则完全需要自己实现了，它需要在ClientA和ClientB之间传送彼此的SDP信息和candidate信息，ClientA和ClientB通过这些信息建立P2P连接来传送音视频数据。由于网络环境的复杂性，并不是所有的客户端之间都能够建立P2P连接，这种情况下就需要有个relay服务器做音视频数据的中转，本文本着源码剖析的态度，这种情况就不考虑了。这里说明一下， stun/turn、relay服务器的实现在WebRTC源码中都有示例，真是个名副其实的大宝库。

上述序列中，标注的场景是ClientA向ClientB发起对聊请求，调用描述如下：

• ClientA首先创建PeerConnection对象，然后打开本地音视频设备，将音视频数据封装成MediaStream添加到PeerConnection中。
• ClientA调用PeerConnection的CreateOffer方法创建一个用于offer的SDP对象，SDP对象中保存当前音视频的相关参数。ClientA通过PeerConnection的SetLocalDescription方法将该SDP对象保存起来，并通过Signal服务器发送给ClientB。
• ClientB接收到ClientA发送过的offer SDP对象，通过PeerConnection的SetRemoteDescription方法将其保存起来，并调用PeerConnection的CreateAnswer方法创建一个应答的SDP对象，通过PeerConnection的SetLocalDescription的方法保存该应答SDP对象并将它通过Signal服务器发送给ClientA。
• ClientA接收到ClientB发送过来的应答SDP对象，将其通过PeerConnection的SetRemoteDescription方法保存起来。
• 在SDP信息的offer/answer流程中，ClientA和ClientB已经根据SDP信息创建好相应的音频Channel和视频Channel并开启Candidate数据的收集，Candidate数据可以简单地理解成Client端的IP地址信息（本地IP地址、公网IP地址、Relay服务端分配的地址）。
• 当ClientA收集到Candidate信息后，PeerConnection会通过OnIceCandidate接口给ClientA发送通知，ClientA将收到的Candidate信息通过Signal服务器发送给ClientB，ClientB通过PeerConnection的AddIceCandidate方法保存起来。同样的操作ClientB对ClientA再来一次。
• 这样ClientA和ClientB就已经建立了音视频传输的P2P通道，ClientB接收到ClientA传送过来的音视频流，会通过PeerConnection的OnAddStream回调接口返回一个标识ClientA端音视频流的MediaStream对象，在ClientB端渲染出来即可。同样操作也适应ClientB到ClientA的音视频流的传输。

这里的流程仅仅是从使用层面上描述了一下，具体内部都做了什么、怎么做的，以后的文章中会慢慢细扒，万事开头难，自我鼓励一下。

本文链接：WebRTC手记之初探，转载请注明。

阅读更多内容