因为一个强大的软件，不能随随便便就因为某些异常或者错误就崩溃了，也不可能就是一大堆代码的堆砌。上面所提到的有些机制：如异常，日志，它们的价值很多时候在软件维护的时候体验出来。根据日志记录，可以查处软件哪里出了问题，如是数据库断了，还是哪个操作流程导致了问题。 而有些机制是在运行时体现价值，如缓存，验证，事务。

但是在使用这些底层机制的时候也要权衡，综合的考虑，如缓存机制，就得明白那些数据要缓存，缓存在哪里，缓存数据时候要加密，缓存多长时间，如何刷新过期了的数据。等等，很多东西要考虑。

3.数据来源仅仅只是考虑了数据库。其实这个问题不是之前的项目的一个问题，但是这里有必要提出。

a)一般在我们开发项目的时候，数据的来源很多时候都是数据库，我们直接操作数据库就行了，但是还得考虑一个问题：如果我们的项目没有自己的数据库，我们的数据来源是来自其他的公司或者服务接口，怎么办？作为架构的设计者，是需要考虑这些的。

可能在项目敲定那天就已经清楚是自己设计数据库还是从其他地方获取数据。但是一个通用的一个架构的就要能够为其他的数据源预留接口。

这里，可能就有了一点”过度设计”的味道了，起初在项目A中所使用的架构没有考虑其他数据源的问题，但是如果在项目B中出现了，怎么办？那么架构就要演化，改进来适应这种情况。

之前也提过，没有必要一上来就设计强大的就架构，而是在项目中改进，演化。开始时候没有考虑到，以后慢慢的加嘛。(比较的纠结)。

上面只是紧紧的从数据层DAL的角度进行了思考，DAL最终还是为业务层BLL提供数据的，所以就考虑DAL以何种方式来被BLL调用，鉴于之前的一些考虑，可以得出一点：不让BLL直到DAL的实现细节，所以接口似乎是个不错的解决办法，Provider的模式也似乎可以排上用场。

于是,Richard就决定在DAL和BLL之前加上接口层来解耦。

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

这个图和因为随着思考的深入，逐渐的发觉：数据源的来源可以很多—数据库，普通文本，XML等等。不同的数据源提供不同的Provider，其实从其他的服务接口获取数据也是一种来源，上面的图之所以单独的把Service Agent分出，主要是因为比较特殊。

而且图中的那些基本功能：Log, Exception等，是到处都用到的。

此时Richard也在头脑中闪现了一些要处理的，可以出现的异常：

1.Data Source is not exits:数据源不存在，因为这个问题很常见，比如在项目运行过程中，数据库断了，或者远程的服务无法访问，等等基本都属于这个问题的。所以这个异常肯定是要处理的。

2.Time out:超时。这个异常很常见，获取的数据过大，或者远程数据源连接超时，等，都可以引发一些问题。

3.如果数据源是其他服务接口提供数据，那么在数据获取时，可能要转换数据格式，如果格式出错，。或者发送的数据不符合一些规则，这个异常一定要处理，因为这些数据可能涉及到安全的问题了：是数据真的不正确，还是被篡改了。

程序就必须对这些异常进行处理：是把原生的异常抛出，然后有业务层决定如果处理；还是决定把异常包装称为另外的一个异常，再抛出；还是最后干脆再DAL就执行自己处理，然后给业务层一个友好的提示，等等。如果数据源是远程的服务，那么如果服务断了，在异常过程中，采用什么样的策略：简单的处理，如抛出异常，记录日志，还是做一些恢复性的操作，如尝试重新连接，等。