dictionary

前言 通过前面的几篇文章，讲解了一个短信服务的架构设计与实现。然而初始方案并非100%完美的，我们仍可以对该架构做一些优化与调整。 同时我也希望通过这篇文章与大家分享一下，我的架构设计理念。 源码地址：https://github.com/SkyChenSky/Sikiro.SMS/tree/optimize （与之前的是另外的分支） 架构是设计的还是演变的？ 架构 该词出自于建筑学。软件架构定义是指软件系统的基础结构，是系统中的实体及实体（服务）之间的关系所进行的抽象描述。而架构设计的 目的 是为了解决软件 系统复杂度 带来的问题。 复杂度 系统复杂度主要有下面几点： 高可用 高性能 可扩展 安全性 维护成本 用户规模 业务规模 系统的复杂度导致的直接原因是业务规模。为了用户流畅放心的使用产品，不得不提高系统性能与安全。当系统成为人们生活不可缺一部分时，避免机房停电、挖掘机挖断电缆导致的系统不可用，不得不去思考同城跨机房同步、异地多活的高可用方案。 答案并非二选一 我认为架构，需要在已知可见的业务复杂度与用户规模的基础上进行 架构设计 ；伴随着技术积累与成长而对系统进行 架构优化 ；用户的日益增长，业务的不断扩充，迫使了系统的复杂度增加，为了解决系统带来新的复杂度而进行 架构演变。 因此，架构方案是在已有的业务复杂度、用户规模、技术积累度、人力时间成本等几个方面的 取舍 决策

本文3.0版本文章 https://mp.weixin.qq.com/s/3s4_PuuESN-Y8QXZHakHtw 本文是NetCore 2.2的，请不要套用3.0 1、如果看不懂本文，或者比较困难，先别着急问问题，我单写了一个关于依赖注入的小Demo，可以下载看看，多思考思考注入的原理： https://github.com/anjoy8/BlogArti/tree/master/Blog.Core_IOC%26DI 2、重要：如果你实现了解耦，也就是 api 层只引用了 IService 和 IRepository 的话，那每次修改 service 层， 都需要清理解决方案，重新编译项目 ，因为这个时候你的api层的dll，还是之前未修改的代码。 3、重要+ ：请注意，依赖注入的目的不是为了解耦，依赖注入是为了 控制反转 ，通俗来说，就是不用我们自己去 new 服务实例 了，所以大家不需要一定去解耦（比如下文说到的 我没有引用 Service层 和 Repository层），我下一个DDD系列，依赖注入就没有解耦，因为我用的是自带的注入，不是Autofac的反射dll ，我解耦的目的，是为了让大家更好的理解，服务是怎么注入到宿主容器里的。 　　说接上文，上回说到了《 八 || API项目整体搭建 6.3 异步泛型+依赖注入初探 》，后来的标题中，我把仓储两个字给去掉了

Hashtable 和 Dictionary <K, V> 类型 1）：单线程程序中推荐使用 Dictionary, 有泛型优势, 且读取速度较快, 容量利用更充分. 2）：多线程程序中推荐使用 Hashtable, 默认的 Hashtable 允许单线程写入, 多线程读取, 对 Hashtable 进一步调用 Synchronized()方法可以获得完全线程安全的类型. 而Dictionary 非线程安全, 必须人为使用 lock 语句进行保护, 效率大减. 3）：Dictionary 有按插入顺序排列数据的特性 (注: 但当调用 Remove() 删除过节点后顺序被打乱), 因此在需要体现顺序的情境中使用 Dictionary 能获得一定方便. HashTable中的key/value均为object类型，由包含集合元素的存储桶组成。存储桶是 HashTable中各元素的虚拟子组，与大多数集合中进行的搜索和检索相比，存储桶可令搜索和检索更为便捷。每一存储桶都与一个哈希代码关联，该哈希代码是使用哈希函数生成的并基于该元素的键。HashTable的优点就在于其索引的方式，速度非常快。如果以任意类型键值访问其中元素会快于其他集合，特别是当数据量特别大的时候，效率差别尤其大。 HashTable的应用场合有：做对象缓存，树递归 算法 的替代，和各种需提升效率的场合。