Stella 知识库--解析论坛的架构(2)
-- 系列文章与Stella Forum v2.0搭配使用效果更好 --
昨天我们讨论了一下sf2.0分三层设计的基本意图：增加代码的易维护性和可读性，增加系统对需求改变的适应性，等等等等....
对于初次接触这种架构的朋友，可能一时难以接受，总觉得分这么多的项目在解决方案里，就不知道该怎么办了，其实...
“不识庐山真面目，只缘身在此山中”。在做开发的时候完全可以把其他项目当成黑盒来处理，就像使用.net framework的其他类库一样。其实对系统的层来说也是这样的，web层绝对不知道还有个data access层存在，因为它这一辈子就和business层打交道了。同样，data access层也只是认识business层一个而已。
回头来看我们的论坛，data access层和business层之间有个factory，这个是起什么作用的呢？
解释之前，先来说这么个事，最近总是有人把我当成SPL的开发者，问我是不是把SPL也开放了？对这个我都说了几万遍了，SPL可是听棠大哥的力作啊，开 源与否应该去问他嘛~~不过好像大家都对使用一个开源的ORM更感兴趣，于是我想，要不要用NHibernate作一个data access层呢？NHibernate是在java上著名的开源ORM项目的.net版。如果可以分别写用SPL和NHibernate的data access层，那岂不是更有意义？
这样问题就来了，假设我们写出了这两个data access层，如果business直接使用data access层，那怎么能做到随意的互换data access层呢?每换一次就修改business的源文件？太夸张了吧...
更好的办法就是在business和data access之间加一个东西，把他们隔离开来，这样，data access更换得时候就不需要改动business。如果有更好的办法，那就是通过某种配置文件来通知这个中间层data access的更改，然后这个中间层根据得到的通知返回给business当前使用的data access 类。实际上，如果你看了sf2.0中的实现这个中间层的factory的代码，那会发现，更换data access的时候甚至连factory都不需要改动，我们所做的，只是改变web.config中的配置。
问题的关键就是factory的实现了。这个是用反射（System.Reflection）的动态生存类实例的办法来完成这个中间层的。具体可以去看代码 ：）
到这大家应该都明白，这个factory适合于隔离那些可能会有改动的项目，比如data access，再比如services。
Services我设计这个的目的是用来存放第三方的一些组件的，比如说log4net和opensmtp，因为是第三方，所以以后改变的可能性很大，为了不影响其他层对这些组件的使用，我也使用了factory将他们做了隔离处理。
factory的隔离效果是怎么出来的呢？大家知道在.net中有个叫接口(interface)的数据类型，这是一种契约。factory对其他层返回 的都是接口，这就保证了隔离效果的稳定性。很自然的，像data access和services里的类都是实现了某种接口的。
昨天我们讨论了一下sf2.0分三层设计的基本意图：增加代码的易维护性和可读性，增加系统对需求改变的适应性，等等等等....
对于初次接触这种架构的朋友，可能一时难以接受，总觉得分这么多的项目在解决方案里，就不知道该怎么办了，其实...
“不识庐山真面目，只缘身在此山中”。在做开发的时候完全可以把其他项目当成黑盒来处理，就像使用.net framework的其他类库一样。其实对系统的层来说也是这样的，web层绝对不知道还有个data access层存在，因为它这一辈子就和business层打交道了。同样，data access层也只是认识business层一个而已。
回头来看我们的论坛，data access层和business层之间有个factory，这个是起什么作用的呢？
解释之前，先来说这么个事，最近总是有人把我当成SPL的开发者，问我是不是把SPL也开放了？对这个我都说了几万遍了，SPL可是听棠大哥的力作啊，开 源与否应该去问他嘛~~不过好像大家都对使用一个开源的ORM更感兴趣，于是我想，要不要用NHibernate作一个data access层呢？NHibernate是在java上著名的开源ORM项目的.net版。如果可以分别写用SPL和NHibernate的data access层，那岂不是更有意义？
这样问题就来了，假设我们写出了这两个data access层，如果business直接使用data access层，那怎么能做到随意的互换data access层呢?每换一次就修改business的源文件？太夸张了吧...
更好的办法就是在business和data access之间加一个东西，把他们隔离开来，这样，data access更换得时候就不需要改动business。如果有更好的办法，那就是通过某种配置文件来通知这个中间层data access的更改，然后这个中间层根据得到的通知返回给business当前使用的data access 类。实际上，如果你看了sf2.0中的实现这个中间层的factory的代码，那会发现，更换data access的时候甚至连factory都不需要改动，我们所做的，只是改变web.config中的配置。
问题的关键就是factory的实现了。这个是用反射（System.Reflection）的动态生存类实例的办法来完成这个中间层的。具体可以去看代码 ：）
到这大家应该都明白，这个factory适合于隔离那些可能会有改动的项目，比如data access，再比如services。
Services我设计这个的目的是用来存放第三方的一些组件的，比如说log4net和opensmtp，因为是第三方，所以以后改变的可能性很大，为了不影响其他层对这些组件的使用，我也使用了factory将他们做了隔离处理。
factory的隔离效果是怎么出来的呢？大家知道在.net中有个叫接口(interface)的数据类型，这是一种契约。factory对其他层返回 的都是接口，这就保证了隔离效果的稳定性。很自然的，像data access和services里的类都是实现了某种接口的。
