.NET 分布式架构开发实战之二 草稿设计

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

这里，可能就有了一点”过度设计”的味道了，起初在项目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就执行自己处理，然后给业务层一个友好的提示，等等。如果数据源是远程的服务，那么如果服务断了，在异常过程中，采用什么样的策略：简单的处理，如抛出异常，记录日志，还是做一些恢复性的操作，如尝试重新连接，等。

之前第一张图中，在DAL上定义一个接口，用来接耦，但是在第二张图有做了一些修改－－把DAL做为服务提供出去。之所以做了这个修改，因为在开始思考的时候，只是认为底层设计的DAL只是给BLL使用。可以发觉到一点：在DAL中，数据可以从远程的服务中获取，那么可能我们这里的DAL也可以作为服务给其他的人设计的DAL使用，也就是说，我们的这里的DAL成了远程服务的数据源。所以做了上面的修改。但是这个思考到还会改进，因为这里面问题(读者朋友可以先自己思考是什么问题)。

今天就写到这里了，谢谢各位！

下篇讲述： .NET 分布式架构开发实战之三 数据访问深入一点的思考

版权为小洋和博客园所有，转载请标明出处给作者。

http://www.cnblogs.com/yanyangtian

转载：http://www.cnblogs.com/yanyangtian/archive/2010/05/24/1742432.html

本文链接：http://www.blueidea.com/tech/program/2010/7752.asp　

出处：博客园
责任编辑：bluehearts

上一页 .NET 分布式架构开发实战(二) [1] 下一页

◎进入论坛网络编程版块参加讨论