本文探讨了电商网站的数据访问层（DAL）及其与ORM的适用性，强调了通过抽象和封装实现的灵活性与可扩展性。文中详细讨论了DAL的特性、数据库分片的策略和风险，以及透明缓存的实施挑战。提出了数据驱动和领域驱动框架的概念，并描述了具体的架构设计与实施细节。

1. 浅谈电商网站数据访问层
（DAL）与ORM 之适用性
2012.11.2
中国，上海

2. What’s Data ?
Data Files、Database、Data Service、etc.
SQL、NoSQL、AWS RDS、SQL Azure、etc.

3. Why DAL ?
抽象不变的：DRY  Don’t Repeat Yourself
封装变化的：SoC  Separation of Concerns

4. DAL 中的不变、变化？
不变的or 一致的(核心)：Interface、SQL、etc.
变化的- 1：Database、ORM Framework、etc.
变化的- 2：Caching、Logging、Sharding、etc.

5. 电商网站DAL 特点(SoC)
• Simple Scalability  读写分离 DAL R/W Routing
• 10x Scalability  DB Sharding  DAL Routing + Aggregation
• Multi-targeting Logging 
Console/File/Log4Net/EntLib/Common.Logging
• Transparent Caching  DAL 支持+ App 慎用 实现难！
• Lazy Loading  DAL 支持+ App 慎用 用好难！
• 99% Availability  Cache High Availability
– 方案1：Dual-write Cache (Memcache) / Cache Replication (AppFabric)
– 方案2：Multi-level Cache  L1 分布式+ L1.5 本地跨应用+ L2 本地应用内

6. .NET 世界ORM 现状
• 10x Scalability：仅NH/MB 有限支持Sharding
– 通过multi-db-session 实现shards 结果聚合、in-memory 结果排序
– NH HQL 不支持Sharding，如：排序，只能通过ICriteria 间接实现
– 长时间未更新，不兼容最新NH，不支持垂直分区及混合分区
• Multi-targeting Logging：
– NH/MB 支持最好，L2S 也支持，但种类不丰富，需扩展
– EF 不支持，有开源爱好者提供了实现，较复杂、有风险
• Transparent Caching：此处略去N 字…
• Lazy Loading：NH/L2S/EF/MB 都支持
• 99% Availability：此处略去N 字…

7. DAL Sharding Demo (ORM Extension) –
NHibernate.Shards (ISessionFactory)

8. DAL Sharding Demo (ORM Plug-in) –
ShardBatis (SQL Interception)

9. DAL Sharding Demo (ADO.NET Extension) –
Enzo SQL Shard (C# Extension Method)

10. DAL Sharding Demo (ADO.NET Provider) –
dbShards

11. DB Sharding 策略
• Sharding is NOT SILVER BULLET for DB Scale-out
• 不适用场景
– 处理事务型应用非常复杂，跨不同DB 事务，很难保证一致性
– 不含Sharding ID 查询较多的场景，即使并行处理，也要全扫描
• 大方向选择(non-global tables)
– Sharding on every table  primary separation  child separation
– Sharding on every table group (sticky)  primary + all children
– Sharding on every table group (non-sticky)  primary + some children
• 小策略选择：Sharding ID、Aggregation、etc.

12. DB Sharding 策略(continued)

13. DB Sharding 风险
• Sharded Data Migration
• Sharded Cluster Management
• Replication Management
• High-availability Management
• Load-balancing Co-existence
• Sharding Policy Change

14. DAL Sharding 难点
• 切片策略
– 精确定位：PK round-robin / PK hashing-modulus / attribute(s)-based
– 查询策略：all-shards iteration / 精确定位
– 遍历策略：sequential / parallel
• 结果聚合
– 方案1：单库SQL 查询 DAL 中完成聚合(order, group, avg, etc.)
– 方案2：跨库union 聚合 RDBMS 直接返回结果
– 方案3：读写分离 多库实时写 同步至单库 单库非实时读
• 基于ORM、自定义实现(ADO.NET)？
• 其它：DB Proxy Sharding、In-mem Sharding？

15. DAL Sharding 难点(continued)
• DB Proxy Sharding：不太适合当前的Ctrip 
性能问题、协议实现、etc.
• In-mem Sharding
– 已在酒店查询服务优化项目架构设计中使用
– 1st-Level Sharding + 2nd-Level Load Balancing 
– 产品库可以这么做，订单库能这么做吗？

16. DAL Sharding 设计参考
1、eBay Data Access Layer (QCon)
2、DAL Sharding 设计方案

17. DAL Transparent Caching
• 现状
– NH 二级缓存Provider：NHibernate.Caches.MemCache
– MB 二级缓存Module：mybatis-memcached-module
– EF：没有内建二级缓存机制，需通过EFCachingProvider 扩展
– L2S：只有一级缓存，没有扩展机制，不推荐用于scale-out 场景
• 难点
– 对Consumer 透明，如Biz Layer 不需要知道缓存的“存在”
– 解决Caching Policy 和Data Consistency 间的矛盾与冲突
– 缓存刷新，拉模式or 推模式？实时推or 消息通知？
• 其它：Cache Provider 与Cache-ware 区别

18. DAL Transparent Caching (continued)
• High Availability 方案1：Multi-node
– Dual-write Cache (Memcache, client-side, non-transactional)
– Cache Replication (AppFabric, server-side, transactional)
– 无论哪个option，都要考虑secondary node selection 问题！
• 2 cache items  2 cache nodes  比较简单
• 3 cache items  3 cache nodes  有点复杂
• x cache items  y cache nodes  如何确保node unavailable 时造成的影响最小？
• High Availability 方案2：Multi-level
– L1 分布式
– L1.5 本地跨应用
– L2 本地应用内
– 无论哪几个options combination，都要考虑sync coordination 问题！

19. DAL 设计参考
1、NoSQL 数据库笔谈
2、James Hamilton

20. 这么多ORMs，众口又难调，如何选择？

21. 1、One Size does NOT Fit ALL !
2、ORM Fx + Customized SQL + 其它
3、DAL 接口+ Base 抽象+ 自定义实现

22. Demo for【DAL 接口+ Base 抽象+
自定义实现】

23. 介绍DDFx 及相关架构

24. What’s DDFx ?
• DDFx 的第一个D 有两层含义：Data and Domain
• DDFx 的第二个D == Driven，意为：…驱动的…
• DDFx 的Fx == (Development / Design) Framework (and Tools)
• DDFx 理解#1：Data-Driven (Development) Framework
• DDFx 理解#2：Domain-Driven (Design) Framework
• DDFx 具体内容尚在不断完善中，但请记住：DDFx
不是万能的，所以，你要懂得：Context + Balance
• DDFx 中某些非关键技术将采用Tech-Talk 方式进行

25. 什么是Domain？
作为软件方面的专家（架构师、开发人员）和领域专家
（客户方业务人员、需求分析人员），所有人在一起创建
领域的模型，这个模型会统一体现两个专业领域的交汇

26. 什么是Data？
Data Files、Database、Data Service、etc.
SQL、NoSQL、AWS RDS、SQL Azure、etc.

27. DDFx 架构

28. DDFx 中几个数字
• 1 座工厂：DDFx Factory
• 2 个车间：Domain Model (N 产品线)
 Repository (N 产品线)
• 3 种贯穿：DTO  Domain Model Intf.  Repository Intf.
• 6 层架构：Presentation  Application/Controller 
Service  Domain  Repository  Resource
• 8 大前端：
– C/S：Console  Windows Forms  WPF
– B/S：ASP.NET Web Forms  Ajax  MVC / MVVM (ViewModel : DTO)
– RIA：Silverlight (.NET 子集)
– Device：Windows Phone 7 (Silverlight 子集)

29. 图表样例- 1：Visual Studio 生成

30. 图表样例- 2：Visual Studio 生成

31. DDFx 架构层次
• 整体架构：6 层架构+ 1 座工厂(DDFx Factory)
• Layer #1：用户表现层(Presentation Layer)
• Layer #2：应用系统层(Application Layer)
• Layer #3：服务表现层(Service Layer, 可选)
• Layer #4：领域模型层(Domain Layer)
• Layer #5：资源访问层(Repository Layer)
• Layer #6：资源层(关系数据库、外部服务、文件系统、etc.)

32. DDFx 架构+ 开发曲线
L1：UI -> VM/DTO (Requirement + UI Dev)
L2：-> Controller (Non-UI Dev) -> IDomain (Façade Intf.) (Arch + Dev Lead)
-> Domain Factory (Arch) -> Local/Service Client (Dev Lead)
L3：-> Local/Service Server -> IDomain (Façade Intf.) (Arch + Dev Lead)
L4：-> RealDomain (Real Façade) -> Biz. Rule + IRepository (Non-UI Dev)
L5：-> Repository Factory (Arch) -> Local/Service Client (Dev Lead)
-> RepositoryBase<T> : IRepository<T> (Dev Lead)
-> SpecialRepository : ISpecialRepository (Non-UI Dev)
-> Data Client / Service Client / etc. (Non-UI Dev)
L6：-> RDBMS / Service Server / File Server / etc. (Requirement + Arch)

33. 探讨：需求变更导致新增字段，
你会怎么做？

34. Q & A