本文不定时更新中……
具备 RESTful 相关知识会更有利于学习 ASP.NET Web API：RESTful API 学习笔记
ASP.NET Web API 官网：https://www.asp.net/web-api
服务 URI Pattern
| Action | Http verb | URI | 说明 |
| Get contact list | GET | /api/contacts | 列表 |
| Get filtered contacts | GET | /api/contacts?$top=2 | 筛选列表 |
| Get contact by ID | GET | /api/contacts/id | 获取一项 |
| Create new contact | POST | /api/contacts | 增加一项 |
| Update a contact | PUT | /api/contacts/id | 修改一项 |
| Delete a contact | DELETE | /api/contacts/id | 删除一项 |
| 返回类型 | Web API 创建响应的方式 |
|---|---|
| void | 返回空 204 （无内容） |
| HttpResponseMessage | 转换为直接 HTTP 响应消息。 |
| IHttpActionResult | 调用 ExecuteAsync 来创建 HttpResponseMessage，然后将转换为 HTTP 响应消息。 |
| 其他类型 | 将序列化的返回值写入到响应正文中;返回 200 （正常）。 |
HttpResponseMessage
可提供大量控制的响应消息。 例如，以下控制器操作设置的缓存控制标头。
public class ValuesController : ApiController
{
public HttpResponseMessage Get()
{
HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.OK, "value");
response.Content = new StringContent("hello", Encoding.Unicode);
response.Headers.CacheControl = new CacheControlHeaderValue()
{
MaxAge = TimeSpan.FromMinutes(20)
};
return response;
}
}IHttpActionResult
public IHttpActionResult Get (int id)
{
Product product = _repository.Get (id);
if (product == null)
{
return NotFound(); // Returns a NotFoundResult
}
return Ok(product); // Returns an OkNegotiatedContentResult
}其他的返回类型
响应状态代码为 200 （正常）。此方法的缺点是，不能直接返回错误代码，如 404。 但是，您可以触发 HttpResponseException 的错误代码。
完善 Help 页
一般都是通过元数据注释（Metadata Annotations）来实现的描述的。
显示接口和属性的描述：
打开 HelpPage 区域的 App_Start 目录下的 HelpPageConfig.cs 文件，在 Register 方法的首行取消注释行：
config.SetDocumentationProvider(new XmlDocumentationProvider(HttpContext.Current.Server.MapPath("~/App_Data/XmlDocument.xml")));
在项目右键属性“生成”页，勾选“XML 文档文件”，并填写与上述一致的路径（App_Data/XmlDocument.xml）。
给接口加上 ResponseType 显示响应描述和示例：[ResponseType(typeof(TEntity))]
在实体模型的属性上加入 RequiredAttribute 特性可提供请求或响应中的实体的属性描述，如：[Required]
推荐使用：Swashbuckle
关于格式
在 WebApiConfig.Register() 中加入以下代码以禁止以 XML 格式输出（请按需设置）：
GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();Json 序列化去掉 k__BackingField
GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new Newtonsoft.Json.Serialization.DefaultContractResolver { IgnoreSerializableAttribute = true };如果属性值为 null 则不序列化该属性
config.Formatters.JsonFormatter.SerializerSettings = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };
Controller：
public ActionResult EvalAge(byte age)
{
return Content($"{age} 岁");
}View：
@Html.Action("EvalAge", new { age = item.age })最近，空心图标和实心图标的讨论变得激烈起来，有言论指出空心图标在视觉上比实心图标看起来更复杂，更容易让用户差生疲劳感和倦怠感。对此，设计师们都各抒己见，一部分人表示赞同这种说法，而另一部分人则表示这样的言论将问题过分了放大化了，并且在证据方面有所欠缺。
图标也可以理解为是网站中的一种指引，是每个新用户都会涉及到的元素，所以无论空心或实心，一个能够令人一目了然，并且记忆深刻的图标才是用户真正喜欢的图标。
以下是小编搜寻的一些空心或实心的图标案例，看看你更倾心于哪一款呢？
1.模糊背景上覆盖着由简单线条、字体和单一的颜色组成的空心图标，这会让整个界面看起来很优雅。不仅如此，这种简易的设计手法也让设计师轻松不少，在效果和操作上都令大家很满意。
2.纯色的背景似乎搭配任何元素都能达到令人意想不到的效果，下面这个案例也不例外。正红色与白色之间的经典配搭，加以可爱的造型，成就了一个俏皮的实心图标设计。界面底部的实心按钮与幽灵按钮也与图标区域前后呼应。
3.APP底部的图标随着用户的任意切换，在空心和实心之间自由转变。实心的图标相比较空心的而言，给人一种更突出和明显的视觉效果，让用户更容易的抓到重点。而主内容左边的卡通小图案同时采用了空心的设置，尽显极简主义。
4.Line的界面似乎代表了大多数APP的图标设计方式。头部和底部的图标选用两种颜色的实心设计，下拉菜单部分使用空心图标。这样的设计虽然比较大众化，但不可否认的是，这样的做法的确让整个界面看起来格外整洁。
5.幽灵按钮虽然简洁大方，但是过多的使用会另界面很单调无味，但如果使用全部实心的图标设计又会觉得很突兀。下面这个案例就想出了一个好方法。既然空心实心都不合适，那不如尝试一下让两者结合在一起吧。
6.两种色差明显的颜色搭配在一起会体现出一种自然而然的时尚感，黑色背景和亮黄色的图标元素就是很典型的例子。强烈的对比色会让空心图标看起来也像实心图标一样，具有突出重点的效果。
7.Metro风格的界面设计也能运用在APP的图标模块中，案例中将各种第三方分享平台的实心图标都用方块元素连接在一起，让原本单调的图标瞬间活跃了起来，给用户一种焕然一新的感觉。
8.传统的导航图标大多会集中在一个区域内，而SevenEleven的APP在此做了很大的突破，将4个部分分别分布在界面的上下左右，简单的界面突然有了运动场的氛围，让APP充满了生命力。
9.天气类应用的看点中总会有气候图标的一席之地，正如这个案例中所表现的，这又是一个空心与实心相结合的图标设计。
10.这也是一个纯色块与实心图标搭配的案例，这个APP的界面设计其实很普通，但正因为图标的设计让网站变得可爱起来。
图标在网页设计中算是一个小单元，但它的重要性大家都有目共睹。空心图标和实心图标在不同的环境中发挥着不同的作用，美化着网页中的小细节。
ASP.NET MVC 如果从控制器输出的是匿名类的集合，那么绑定到视图时会报错：
“object”未包含“xxx”的定义
简单的解决方法是 JSON 序列化再反序列化，例如：
ViewBag.list = JsonConvert.DeserializeObject(JsonConvert.SerializeObject(q.ToList()));上面是 ViewBag 的情形，如果是直接 return View(匿名类集合);
那么在视图页面：
@model IEnumerable<dynamic>Font Awesome 从 5.0 版本开始，在保持经典的 Web Fonts with CSS 外，还提供更现代化，功能更强大的 SVG with JS 部署方式。
升级为 SVG with JS 后，如果部分图标不显示，可能的原因是：
· 部分在老版本中的图标不再 5.0 版本上提供，解决的方法是引用 fa-v4-shims.js；
· 此方式把 <i /> 标签通过 JS 替换为 <svg /> 标签，须要改动 CSS 样式。
如果仍然使用 Web Fonts with CSS，部分图标不显示，可能的原因是：
· 新版本不再推荐以 fa 的 class 引用，对 Solid（实心）、Regular（标准）、Light（简洁）、Brands（品牌）四大分类分别使用新的命名方式：fas、far、fal、fab。具体可以在 Font Awesome 官网上找到相应图标后，点击打开图标详情，复制已经生成的 HTML 代码。fa 将被视为 fas。
UEditor 的 ASP 版本在虚拟空间上传文件失败，提示“上传错误”或“上传失败，请重试”等，是因为其文件上传组件在创建目录时，没有网站目录外的访问权限。
例如上传文件的磁盘保存路径为：
D:\web\sitename\wwwroot\upload\20180523\123.jpg
百度编辑器的上传组件会依次判断以下目录是否存在，不存在则创建：
D:\
D:\web\
D:\web\sitename\
D:\web\sitename\wwwroot\
D:\web\sitename\wwwroot\upload\
D:\web\sitename\wwwroot\upload\20180523\
虚拟空间自动配置的网站根目录可能是：
D:\web\sitename\wwwroot\
所以，判断存在或创建以下目录没有问题：
D:\web\sitename\wwwroot\upload\
D:\web\sitename\wwwroot\upload\20180523\
但判断存在以下目录时会因为权限不足而失败：
D:\
D:\web\
D:\web\sitename\
解决方法是找到文件 asp/Uploader.Class.asp
找到 CheckOrCreatePath 这个 Function，替换为：
Private Function CheckOrCreatePath( ByVal path )
Set fs = Server.CreateObject("Scripting.FileSystemObject")
Dim parts
Dim root : root = Server.mappath("/") & "\"
parts = Split( Replace(path, root, ""), "\" )
path = root
For Each part in parts
path = path + part + "\"
If fs.FolderExists( path ) = False Then
fs.CreateFolder( path )
End If
Next
End Function另外，如果服务端无法通过 Request.Form 来接收该值，把 <form /> 放到 <table /> 外面试试。
或者绑定 contentChange 事件来赋值（不推荐）：
ue.addListener("contentChange", function() {
document.getElementsByName('xxxxxx')[0].value = ue.getContent();
});此方法的缺点是，不是所有操作都能触发 contentChange 事件，比如剪切、上传图片等。
改进方法（推荐）：在 form 提交之前赋值。
本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)
本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。
以一张包含 2000 万条记录的表做实验：
CREATE TABLE `dt_read` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`time` datetime(0) NOT NULL,
`a_id` int(11) NOT NULL,
PRIMARY KEY (`id`) USING BTREE
);这张表是用于记录文章点击量的，
`id` 为主键，int(11) 自增；
`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；
`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。
体验“全表扫描”
首先来体验一下什么是全表扫描，执行下面语句：
SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10
> 时间: 0.012s
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10
> 时间: 7.317s
表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。
索引对 ORDER BY 的 ASC 和 DESC 的影响
我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10
> 时间: 0.012s
创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。
试试按 `time` 倒序排：
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10
> 时间: 0.013s
结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。
索引字段的次序对 WHERE 和 ORDER BY 的影响
删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。
分别执行以下查询：
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10
> 时间: 0.013s
结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。
但在 ORDER BY 中却不是这么回事了：
SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10
> 时间: 14.066s
原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。
索引中的字段必须依次使用
保持上例创建的索引不变，即 `time`, `a_id`。
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10
> 时间: 6.438s
上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。
我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：
SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10
> 时间: 29.566s
WHERE 和 ORDER BY 混合
保持上例创建的索引不变，即 `time`, `a_id`。
先来执行这两句：
SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10
> 时间: 12.29s
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 0.013s
仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。
我们把时间改大，让它能马上找到符合条件的数据：
SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 22.34s
为什么这个语句就不走索引了呢？
其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。
当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。
当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。
现在把索引改成只有 `time` 一个字段。
SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 6.033s
因为索引里有 `
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10
> 时间: 6.033s
第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。
索引中的字段越多越好
分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：
本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。
SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10
仅创建索引（`time`）的情况下：
> 时间: 0.013s
仅创建索引（`time`, `a_id`）的情况下：
> 时间: 0.013s
SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10
仅创建索引（`time`）的情况下：
> 时间: 15.015s
仅创建索引（`time`, `a_id`）的情况下：
> 时间: 0.014s
可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。
虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。
索引对 INSERT / UPDATE / DELETE 的效率影响
分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：
INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)
不建索引的情况下：
> 时间: 0.01s
仅创建索引（`time`）的情况下：
> 时间: 0.01s
同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：
> 时间: 0.01s
UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）
不建索引的情况下：
> 时间: 0.01s
仅创建索引（`time`）的情况下：
> 时间: 0.01s
同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：
> 时间: 0.01s
虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。
一些误区
“in 语法效率很低”?
in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。
另外：
对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。
索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。
本文系个人实践总结，欢迎批评指正！
在 Global.asax 的 Application_Start() 方法中添加以下代码，作用是在应用程序启动时预先访问一遍所有动态页面，办法虽土，但很有效。
本代码适合 Web Forms 项目，不适合 MVC 项目；修改代码中的 domain 值为真实的网站域名
代码整理中……
在 IIS 中设置应用程序池最长时效或永不过期，则效果更佳。
在应用程序池中选中网站对应的应用程序池，在右侧“操作”窗口中选择“正在回收...”
取消“固定间隔”框中的所有选项，确定。
实践证明，近 200 个动态页面一次性访问需要耗时近 10 分钟，发布后 10 分钟内无法正常浏览网站是同样是无法忍受的。因此更改方案为：
做一个 Winform 应用程序来定时访问这些页面，30 秒一个，一个半小时能完成一个循环，对正常浏览的影响非常小。
更新 .edmx 文件时若提示：
生成模型时出现意外错误。有关详细信息，请参阅输出窗口。异常消息:“StrongTypingException: 表“TableDetails”中列“IsPrimaryKey”的值为 DBNull。”。
可以通过以下方法来解决：
1，控制面板中打开“服务”（或执行命令 services.msc），重新启动“MySQL57”
2，在 MySQL 中执行：
use <<database name>>;
set global optimizer_switch='derived_merge=OFF';如果提示“1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation”，请使用超级用户进行操作。
3，搞定，试试更新 .edmx 吧。