本文只是一个简单的知识点，撰文起因是之前在项目中用到内部类的JSON序列化有问题，后来发现是自己写法错误。这里权当一个记录吧。

在通过继承方式实现语言的多态性时，对有转换和替换关系的基类、子类对象进行JSON的序列化和反序列化，需要设置JsonSerializerSettings中的类型名称TypeNameHandling枚举才能生效。

- 阅读剩余部分 -

工作中经常会开发一些接口公布出去，接口以HTTPHandler方式挂载在ASP.NET上，是以*.filetype的后缀形式路由到具体的处理类中。接口参数以JSON格式通过post方法写在Request body中，宿主的ERP系统并没有提供对应的参数校验框架，因此无法像其他基于其他API框架的形式，对输入参数进行统一的校验。

本文针对这种情况，将介绍下JSON.NET自带的JSON Schema校验方式。

- 阅读剩余部分 -

在写SQL语句时，有时候需要对表中的行进行拼接，这时候可以使用STUFF()和for xml path()语句：

如有表如下：

id  |   name
----------
1   |   aaa
1   |   bbb
1   |   ccc

你想得到的结果如下：

id  |   result
--------------
1   |   aaa,bbb,ccc

有的在业务系统中通过多次查询拼接也可以得到如上结果，但是多次查询数据库会更麻烦。这里可以使用TSQL的STUFF函数和for xml path()方法。

- 阅读剩余部分 -

在第二篇文章中介绍了如何利用工作队列将耗时任务分发到多个消费者工作程序中。

考虑下另一种情况：如果需要在一个远程机器上执行一个函数然后等待它的返回结果应该怎样？这个过程称之为远程过程调用(RPC:Remote Procedure Call).

本篇将介绍如何利用RabbitMQ实现一个包含客户端和可扩展服务端的RPC系统，仍然跟之前的一样，利用模拟计算来替代真实的耗时任务，这里使用计算斐波那契数列函数。

- 阅读剩余部分 -

在上一篇文章中，我们对之前的日志系统进行了改进，使用direct类型的exchange替代了只能广播消息的fanout类型，让日志系统能够有选择性的接收处理消息。

虽然使用direct类型的exchange提升了日志系统的扩展性，但还是有它的局限性存在，那就是无法配置多重标准的路由。

如果想让系统不能仅根据日志级别来定义，还能根据发送日志的源信息来订阅。如unix工具syslog，就是根据日志级别(info/warn/crit..)和设备(auth/cron/kern)来进行路由的。这会提供更多的灵活性，如可以做到监听所有来自'cron'和'kern'设备的error信息。

为了实现这种灵活性，需要来学习下另外一个功能更综合的topic类型的交换器(exchange).

- 阅读剩余部分 -