前言：本篇之所以称为草稿设计，是因为设计的都是在纸上完成的。反映了一个思考的过程。

本篇的议题如下：

1.第一个数据层草图的提出

2.对数据访问层的思考

3.第二个数据层草图的提出

1.数据层草图的提出

Richard开始着手设计，一开始他没有就立刻在自己的计算机开始敲代码。而且采用笔＋纸开始构思。

因为他认为：写程序不是什么时候都得上机，脑子里面想什么的才是最重要的，往往很多时候，在设计程序时，首先在头脑中就已经把整个功能已经实现了，甚至代码的详细编写都已经在头脑中走了一遍，并且在头脑中”运行，调试”了。

开始设计了，因为这次Richard想要提出一个比较好的架构，一个比较强大的企业级的架构，所以参看成功的一些案例是很有必要，Richard也就想到了微软best practice的那些推荐的架构组织方式和建议（大家对best practice不熟悉也要紧，不会影响阅读）。

之后，Richard的第一个草图就出来了：

一个架构组织方式的提出，不是随随便便就提出的，新的架构的设计和提出首先必须要明白你要解决哪些问题，而且也不要”过度设计”。(这个过程很难，很多时候需要权衡，所以作为架构的设计者，权衡的思想很重要：在时间，资源，资金等都要考虑)。可能在起初会参看一些别的设计架构，甚至是模仿它们，但是随着思考的深入，那些表象的东西就会逐渐的被抛除。

同时也开始设计的时候，没有说一定要立刻就要设计出一个很强大的东西出来，对架构设计的能力也是在慢慢的演化和思考过程中提升的。

2.对数据访问层的思考

在解释为什么架构要像上面那副图进行设计之前，我们首先来讨论一些之前项目问题：

对于数据访问层(DAL)的问题：

1.DAL很依赖Linq生成的实体。可以说在之前的项目中，在数据访问层能够使用的技术就已经”钉死”在了Linq上。这里不是说Linq不好，而且强调在DAL的访问技术的选择的余地已经没有了，不灵活。

a)在架构的设计过程中，就需要考虑到以后技术的转变和更换，可能在项目A中采用Linq to sql，但是在项目B中就采用Entity Framework。因为我们的目的就是要开发一个比较灵活的通用架构，能够支持不同就数据访问技术。可能以后的项目都只是用一种访问技术，但是最为架构的设计者，特别是希望从架构最后能够演化到Framework, 那就要为更换技术预留接口。

2.在DAL中没有很多的异常处理等底层机制。

a)在项目设计的过程中，有些底层的机制是几乎每一个逻辑都要用到的：异常处理，日志跟踪，缓存机制，事务机制，安全验证机制。当时在之前的DAL中是没有的。可能现在你认为有些机制不是需要的，或者不明白为什么需要。