JSON解析类(C#) 改进版
示例代码：
分类：Web编程
共 938 篇JSON解析类(C#)
调用示例：
奇妙的C#属性：属性 or 方法？
调用示例： 测试说明 ·只有this后边能跟中括号； ·this后边不能跟小括号，即不能写成方法； ·this只能为属性，不能为方法；
让C#类支持关联数组
using System; using System.Collections; using System.Collections.Generic; namespace ConsoleApplication1 { class Program { static void Main(string args) { TestClass t = new TestClass(); //添加遍历 t = "111"; t = "222"; t = "333"; foreach (string item in t) { Console.…
Effective C# 原则34：创建大容量的Web API
交互协议的开销与麻烦就是对数据媒体的如何使用。在交互过程中可能要不同的使用媒体，例如在交流中要不同的使用电话号码，传真，地址，和电子邮件地址。让我们再回头来看看上次的订购目录，当你用电话订购时，你要回答售货员的一系列问题： "你可以把第一项填一下吗？" "这一项的号码是123-456" "您想订购多少呢？" "三件" 这样的问题一直要问到销售人员填写完所有的信息为止，例如还要知道你的订购地址，信用卡信息，运送地址，以及其它一些必须的信息来完成这笔交易。在电话上完成这样一来一回的讨论还是令人鼓舞的。因为你不会是一个人长时间的自言自语，而且你也不会长时间忍受销售人员是否还要哪里的安静状态。 与传真订购相比，你要填写整个订购文档，然后把整个文档发给公司。一个文件一次性传输完成，你不用很填写产品编号，发传真，然后填写地址，然后再传真，填写信用卡号，然后再发传真。…
Effective C# 原则33：限制类型的访问
并不是所有的人都须要知道所有的事。也不是所有的类型须要是公共的。对于每个类型，在满足功能的情况下，应该尽可能的限制访问级别。而且这些访问级别往往比你想像的要少得多。在一个私有类型上，所有的用户都可以通过一个公共的接口来访问这个接口所定义的功能。 让我们回到最根本的情况上来：强大的工具和懒惰的开发人员。VS.net对于他们来说是一个伟大的高产工具。我用VS.net或者C# Builder轻松的开发我所有的项目，因为它让我更快的完成任务。其中一个加强的高产工具就是让你只用点两下按钮，一个类就创建了，当然如果这正是我想要的话。VS.net为我们创建的类就是这样的： 这是一个公共类，它在每个使用我的程序集的代码块上都是可见的。这样的可见级别太高了，很多独立存在的类都应该是内部(internal)的。你可以通过在已经存在的类里嵌套一个受保护的或者私有的类来限制访问。 越低的访问级别，对于今后的更新整个系统的可能性就越少。越少的地方可以访问到类型，在更新时就越少的地方要修改。…
Effective C# 原则32：选择小而内聚的程序集
这一原则实际应该取这个名字：“应该创建大小合理而且包含少量公共类型的程序集”。但这太沉长了，所以就以我认为最常见的错误来命名：开发人员总是把所有的东西，除了厨房里水沟以外(译注：夸张说法，kitchen sink可能是个口语词，没能查到是什么意思，所以就直译了。)，都放到一个程序集。这不利于重用其中的组件，也不利于系统中小部份的更新。很多以二进制组件形式存在的小程序集可以让这些都变得简单。 然而这个标题对于程序集的内聚来说也很醒目的。程序集的内聚性是指概念单元到单个组件的职责程度。聚合组件可以简单的用一句话概括，你可以从很多.Net的FCL程序集中看到这些。有两个简单的例子：System.Collections程序集就是负责为相关对象的有序集提供数据结构，而System.Windows.Forms程序集则提供Windows控件类的模型。Web form和Windows Form在不同的程序集中，因为它们不相关。你应该用同样的方式，用简单的一句话来描述你的程序集。不要玩花样：一个MyApplication程序集提供了你想要的一切内容。是的，这也是简单的一句，但这也太刁懒了吧，而且你很可能在My2ndApplication(我想你很可能会要重用到其中的一些内容。这里“其中的一些内容”应该放到一个独立的程序集中。)程序集并不须要使用所有的功能。 你不应该只用一个公共类来创建一个程序程序集。应该有一个折衷的方法，如果你太偏激，创建了太多的程序集，你就失去了使用封装的一些好处：首先就是你失去了使用内部类型的机会，内部类型是在一个程序集中与封装(打包)无关的公共类(参见原则33)(译注：简单的说，内部类型就是只能在一个公共的程序集中访问类，程序集以外限制访问)。JIT编译器可以在一个程序集内有很的内联效率，这比起在多程序集中穿梭效率要高得多。这就是说，在一个程序集中放置一些相关的类型对你是有好处的。我们的目标就是为我们的组件创建大小最合适的程序集。这一目标很容易实现，就是一个组件应该只有一个职责。…
Effective C# 原则31：选择小而简单的函数
做为一个有经验的程序员，不管你在使用C#以前是习惯用什么语言的，我们综合了几个可以让你开发出有效代码的实际方法。有些时候，我们在先前的环境中所做的努力在.Net环境中却成了相反的。特别是在你试图手动去优化一些代码时尤其突出。你的这些行为往往会阻止JIT编译器进行最有效的优化。你的以性能为由的额外工作，实际上产生了更慢的代码。你最好还是以你最清楚的方法写代码，其它的让JIT编译器来做。最常见的一个例子就是预先优化，你创建一个很长很复杂的函数，本想用它来避免太多的函数调用，结果会导致很多问题。实际操作时，提升这样一个函数的逻辑到循环体中对.Net程序是有害的。这与你的真实是相反的，让我们来看一些细节。 这一节介绍一个简单的内容，那就是JIT编译器是如何工作的 。.Net运行时调用JIT编译器，用来把由C#编译器生成的IL指令编译成机器代码。这一任务在应用程序的运行期间是分步进行的。JIT并不是在程序一开始就编译整个应用程序，取而代之的是，CLR是一个函数接一个函数的调用JIT编译器。这可以让启动开销最小化到合理的级别，然而不合理的是应用程序保留了大量的代码要在后期进行编译。那些从来不被调用的函数JIT是不会编译它的。你可以通过让JIT把代码分解成更多的小块，从而来最小化大量无关的代码，也就是说小而多的函数比大而少的函数要好。考虑这个人为的例子： 在BuildMsg第一次调用时，两个选择项就都编译了。而实际上只有一个是需要的。但是假设你这样写代码：…
Effective C# 原则30：选择与CLS兼容的程序集
.Net运行环境是语言无关的：开发者可以用不同的.Net语言编写组件。而且在实际开发中往往就是这样的。你创建的程序集必须是与公共语言系统(CLS)是兼容的，这样才能保证其它的开发人员可以用其它的语言来使用你的组件。 CLS的兼容至少在公共命名上要与互用性靠近。CLS规范是一个所有语言都必须支持的最小操作子集。创建一个CLS兼容的程序集，就是说你创建的程序集的公共接口必须受CLS规范的限制。这样其它任何满足CLS规范的语言都可以使用这个组件。然而，这并不是说你的整个程序都要与CLS的C#语言子集相兼容。 为了创建CLS兼容的程序集，你必须遵从两个规则：首先，所以参数以及从公共的和受保护的成员上反回的值都必须是与CLS兼容的。其次，其它不与CLS兼容的公共或者受保护成员必须存在CLS兼容的同意对象。…
Effective C# 原则29：仅在对基类进行强制更新时才使用new修饰符
你可以用new修饰符来重新定义一个从基类中继承来的非虚成员。你可以这样做，但并不意味着需要这样做。重新定义非虚方法会导致方法含意的混乱。如果两个相关的类是继承关系，那么很多开发人员可能会立即假设两段代码块是做完全相同的事情，而且他们也会这么认为： 一但使用了new修饰符以后，问题就完全不一样了： 这样的实际操作会让很多开发人员迷惑。因为当你在同一个对象上调用相同的函数时，一定希望它们执行同样的代码。但实际上是，一但你用不同的引用来调用同名的函数，它们的行为是不一样的，这感觉非常糟糕。它们是不一致的。一个MyOtherClass类型的对象所表现的行为会因为你引用的方式不一样而有所不同。这就是new修饰符用在非虚成员上的后果。其实这只是让你在类的名字空间中添加了一个不同的方法(虽然它们的函数名是相同的)。…