Microsoft Azure开发体验 – 网络报名系统

去年底RP好抢到了中国版Azure的使用机会，最近社团里讨论到9月份招新的问题，就用Azure Website和Azure Table Storage打造了这个报名系统。

网站放在 http://joinit.zjyz.org/ ，一个很简单的页面，用的是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 中国版与国际版的对比

白海石 《Windows Azure 实战》机械工业出版社