Net应用架构设计

N-Tier

是从架构更大的维度上划分，每个维度都是一个Tier（在微软的ESP2.0里翻译为”级”），好比电商架构划分以下：

1. UI
2. 服务接口
3. 消息、缓存中间件
4. 数据库
5. ......

Tier与Tier之间经过Tcp/Http通信，而且每一级均可以独立部署。

N-Layer

相对Tier，Layer是更细粒度的划分，好比服务接口Tier就能够划分为：表示层、业务逻辑层和数据访问层三个Layer。每个Layer是没有必要独立部署的，不然只会更影响性能。

总结

Tier通常指物理上的分层，Layer是逻辑上的分层。

分层重要思想

职责分离和关注点分离。

架构拆分的经常使用方法

1. 化整为零
2. 动静分离
3. 按功能拆分

Anemic Domain Model

贫血型领域模型模式，和Domain Model很像，主要区别以下：

1. Domain Model的领域类中包含了自身的业务逻辑和数据，以及对象之间的关系
2. 贫血型的领域类将与自身相关的业务处理逻辑所有转移到了模型以外--有专门的业务规则类，这使得领域类成为了一个简单的数据对象。

策略模式

把不一样的算法和行文分别封装成独立的对象（类），实现统一的策略接口；具体业务依赖于策略接口，从而能够灵活实现算法、行为的切换。主要解决在有多种算法类似的状况下，使用 if...else 所带来的复杂和难以维护问题。

装饰者模式

核心思想优先采用组合而不是继承。

模板方法

最直接的理解就是“模板”：包括变化和不变化的两个部分，将变化的部分交给子类实现。一个重要的点就是“钩子”函数，一种被声明在抽象类中的方法（空的和默认的实现），可让子类本身决定对算法的不一样点进行挂钩。

 

 

策略模式是除了继承以外的一种弹性方案。若是采用继承来定义一个类的行为，咱们将会被这个行为困住，甚至修改起来很困难。有了策略模式，就能够经过组合不一样的策略对象来改变行为。

 

服务定义粒度：

1. 不要使用泛泛的UpdateCustomerDetails来定义操做，而要用ChangeCustomerAddress、RecordCustomerMarriage之类的有业务意义的名称来定义操做。操做简单、易于理解，从而提升了易用性。
2. 若是服务使用的范围有限，如仅仅在企业内部应用集成，则能够选择相对较细粒度的服务接口，为服务请求者提供更多灵活性，若是服务使用的范围扩大，服务的大小也应随之扩大，如企业外部集成
3. 多参数时采用结构化，我的认为超过3个时最好用结构化入参。操做灵活，不干扰现有使用者的状况下提供新版本。

 

预定保留模式

1. 发送一个请求给服务器，从服务端的响应中获取一个预定保留的惟一编号（有必定期限，为了不资源耗费及一些安全性问题）
2. 客户端余下的请求中都会带上这个编号，以便服务器把这些请求当成一个事务来处理

等幂模式

1. 每一次客户端请求都被赋予了一个惟一的请求标识（生成规则多是经过这个请求的一些参数作一些算法来生成）
2. 服务端在一个存储区域检查这个惟一的标识所表明的请求是否已经被处理过了，是否有对应的响应信息，若是有就从响应存储设备（如数据库、缓存）中返回响应信息，若是没有再次处理这个请求。