去年底RP好抢到了中国版Azure的使用机会，最近社团里讨论到9月份招新的问题，就用Azure Website和Azure Table
Storage打造了这个报名系统。
网站放在 http://joinzjazure.chinacloudsites.cn/
，一个很简单的页面，用的是bootstrap的CSS，针对不同分辨率的屏幕做了优化，在手机上也可以有不错的体验。
基础知识
阅读本文，我假定你具有以下知识：
- C# 基础知识
- ASP.NET MVC 基础知识
- 知道 Azure 的概念
ASP.NET 与 Azure Website
数据校验
根据报名表上面的字段，我设计出了这样的数据模型，用 System.ComponentModel.DataAnnotations
命名空间下的用于数据验证的Attribute进行验证，这是部分代码
大家可能发现我的代码和平常的C#有点不一样，那是因为我装了微软Roslyn 项目的预览版，体验了下C#6.0的功能，
这种写法叫Primary constructor,其实这个功能在F#早就有了，C#借鉴F#的这一点，挺不错的，
从Primary constructor 获取了参数，可以用这些参数初始化自动属性，写得非常爽。
好了，又扯远了，回到数据验证的话题，微软给我们提供了很多数据验证的Attribute，下面是常用的
| Attribute | 用途 |
|---|---|
| Required | 必须字段 |
| MaxLength | 限制最大长度 |
| MinLength | 限制最小长度 |
| EmailAddress | 邮箱地址验证 |
| Phone | 电话号码验证 |
| Range | 限定数值范围 |
| RegularExpression | 正则表达式验证 |
另外，个人觉得比较有意思的一个是在System.Web.Mvc
下面的Remote，可以调用一个特定的Action进行验证，比如检查用户名是否已经被注册。
客户端验证
定义好数据规则后，需要考虑的是验证方式，这里我选择客户端验证，因为客户端验证可以做到用户一边输入一遍验证，而不用等到点击了submit以后才发现填错了一堆东西，那样的体验肯定不好，
再者，客户端验证还可以减轻服务器的负担，何乐而不为呢？客户端验证的一大缺点是，一旦有人绕过了这个验证，那就…
当然，这是只防君子不防小人的。
实现客户端验证非常简单，首先添加Nuget包：
第二步，把用于数据验证的JavaScript 加到页面上去
此时的页面已经具有验证数据的功能，但为了显示错误信息，还要在页面加上一些东西
好了，大功告成，测试一下，哈哈
使用Bundle 减少请求数
一个页面有很多图片 、JavaScript 和 CSS 要加载进来，
获取每一个资源浏览器都要发起一个请求（不考虑缓存），请求多的话，网页加载的速度肯定不快，于是我们考虑到去减少请求数，最简单的方法是把JS和CSS文件合并，但是，合并以后，破坏了原有的文件结构，况且不同的页面需要不同的文件组合。
那么，能不能根据需要动态组合文件呢，ASP.NET的Bundle为我们解决了这个问题
在ASP.NET MVC项目模板带有一个BundleConfig的类，里面已经带有jQuery和bootstrap了，我们把需要的jQuery
validation加进去
经过这样的处理后，我们可以在页面里这样引用文件
值得一说的是这个属性
在我们调试的时候，把他设为false，文件会被单独加载，方便调试，在生产环境里，把他设为true，打开优化，提高性能。
小组信息存储
社团内部的几个小组，信息结构一致，可以抽象成这样一个类。数据的改动不大，但又不想硬编码到网页，于是考虑放到一个XML文件里面
页面加载时，使用 GroupXmlStore 类从XML加载数据，LINQ to XML挺好用的
在网页里面foreach出来就好了
发布到Azure Website
发布到Azure最简单不过了，项目右键选择Publish，根据提示操作即可
配置文件
我们会把网站的一些经常变动的设置放到Web.config里面，在Azure
Website上，可以在管理门户方便地更改Web.config里的设置，但他不会把当前Web.config里的app settings
读取出来，要自己添加，希望改进
这里的更改不会改动Web.config里面的值，但这个设置的优先级比Web.config的高，可以覆盖掉Web.config里面的设置，因此通过获取AppSetting代码获取到的是这里的值。
Azure Table Storage 与 数据模型
为什么选择Azure Table Storage
既然网站在云端，数据当然放在云端，Azure对于有一定结构的数据的存储提供了两种选择：Azure Table Storage 和 SQL
Database，下面的是我摘自MSDN的一个比较
| Comparison Criteria | Azure Table Storage (NoSQL) | SQL Database (RDB) |
|---|---|---|
| Data relationships | No | Yes |
| Server-side processing | No | Yes |
| Transaction support | Limited | Yes |
| Geo-replication | Yes | No |
| Table schema | Relaxed | Managed |
| Similarity to existing data stores used on-premises | No | Yes |
| Scale-out | Automatic | Manual |
| Data types | Simple | Simple, Complex, and User Defined |
报名表的数据结构是固定的，而且数据之间没有关系，因此我选择了Azure Table Storage，关于二者的详细比较，请参阅MSDN: Windows Azure Table Storage and Windows Azure SQL Database -
Compared and Contrasted
数据模型
Azure Table Storage 有Entity有三个保留字段
RowKey、PartitionKey和Timestamp，其中RowKey和PartitionKey作为记录的唯一标识，也就是说，如果两个Entity的RowKey和PartitionKey
都相同，那就是同一个Entity。在报名表里面，班级和姓名同样有这样的特点，毕竟同班同名的几率是非常小的，这样，可以考虑把班级和姓名作为PartitionKey和RowKey，RowKey作为姓名，Partition做这样的分割：三位，第一位为年级，后两位为班级，下图表示高一(29)班。
上文提到的小组，里面数值为1 2 4 8 的value可能有点令人费解，不过相信有的朋友已经猜到了，我在Azure Table Storage
里面是用一个int存储小组信息的，每个二进制位对应一个小组，在查看数据时，做这样的解析即可
对实体进行操作
对Azure
Table的操作就比较简单了，首先获取Table的实例，然后新建一个operation，最后在table上执行这个operation即可。
Azure Table的插入操作有三种：
- Insert 普通的插入操作
- InsertOrReplace 如果实体不存在，插入实体，否则替换实体
- InsertOrMerge如果实体不存在，插入实体，否则合并实体，所谓的合并是指把新旧实体的属性进行并集操作，比如说，旧的实体有A，B两个属性，新的实体有B，C两个属性，那么Merge以后的实体有A，B，C三个属性。
对中国版Azure的一些吐槽
Azure是个不错的东西，但由某些众所周知的原因，中国版的Azure和国际版的Azure是分开的，功能上我只能说残废，没有Media
Service也就算了，居然没有Mobile Service， AD不能新建，SQL Database
不能Sync，管理门户的语言切换有很大的bug，根本换不过来，只好跑到"我的账单"里面换过来，再回到管理门户，而且管理门户只能用Azure的AD账号登陆，不能用outlook邮箱，太多槽点不说了。
还有一个问题，我昨晚把网址发给我一个在加拿大的同学，打不开，DNS错误，难道中国版Azure只能在中国这个局域网里面用？
唉，算了，毕竟中国版Azure不是微软亲生的，快快长大，到18岁办个VISA卡注册国际版Azure。
参考资料
Microsoft Windows Azure Table Storage and Windows Azure SQL Database -
Compared and Contrasted
陈希章 优化网站设计（一）：减少请求数
白海石 《Windows Azure 实战》机械工业出版社
Microsoft Azure开发体验 – 网络报名系统,码迷,mamicode.com