系统架构设计 & 避免循环引用……
今天有同事问这个问题，记得以前也曾遇到过类似问题，特记录下来，免得再次忘记。
下面这个系统结构图，恐怕大家都很熟悉。
这种结构非常简单，而且其好处十分明显：
1. 架构设计师完成设计后，使用工具直接生成Facade Library框架，将界面和类库开发进行分离。由于完全基于接口和外观模式，使得界面和类库之间的耦合降到最低。
2. 界面程序员可以直接使用数据模拟类来进行开发，而无需等待类库(Concerte Library)开发完成。
3. 类库可以灵活升级，甚至提供多个版本，而UI无需做任何修改。
好处是不少，可是这个设计存在几个问题：
1. Facade.NewTest() 需要引用Concerte Library类库才能生成ConcerteTest实例，而ConcerteTest又必须引用Facade Library类库才能继承Test类或实现ITest接口。显然这种循环引用(见下图)会造成无法编译。解决方法只能是将Facade Library和Concerte Library合并成一个类库，这会造成设计框架和实现框架无法分离，为系统后续设计和开发带来潜在麻烦。
2. 即便某种语言可以忽略循环引用的问题，Concerte Library的修改也可能需要重新编译Facade Library，对于一个庞大系统来说，这并不是个好主意。
为了解决这些问题，我们将这个结构拆借，分离成如下样式的结构。
我们将Facade Library中的接口和抽象类分离出来，形成一个单独的Interface Library。如此分解以后，循环引用的问题被解决(见下图)，而且Concerte Library的变化也只需重新编译Facade Library，由于该类库非常简单(可能只有Facade类)，因此也避免了上面提到的编译问题。在不破坏设计框架和实现框架分类的前提下，稍微的复杂度显然能给我们带来更多的好处。
转载自:http://www.rainsts.net/article.asp?id=152
下面这个系统结构图，恐怕大家都很熟悉。
这种结构非常简单，而且其好处十分明显：
1. 架构设计师完成设计后，使用工具直接生成Facade Library框架，将界面和类库开发进行分离。由于完全基于接口和外观模式，使得界面和类库之间的耦合降到最低。
2. 界面程序员可以直接使用数据模拟类来进行开发，而无需等待类库(Concerte Library)开发完成。
3. 类库可以灵活升级，甚至提供多个版本，而UI无需做任何修改。
好处是不少，可是这个设计存在几个问题：
1. Facade.NewTest() 需要引用Concerte Library类库才能生成ConcerteTest实例，而ConcerteTest又必须引用Facade Library类库才能继承Test类或实现ITest接口。显然这种循环引用(见下图)会造成无法编译。解决方法只能是将Facade Library和Concerte Library合并成一个类库，这会造成设计框架和实现框架无法分离，为系统后续设计和开发带来潜在麻烦。
2. 即便某种语言可以忽略循环引用的问题，Concerte Library的修改也可能需要重新编译Facade Library，对于一个庞大系统来说，这并不是个好主意。
为了解决这些问题，我们将这个结构拆借，分离成如下样式的结构。
我们将Facade Library中的接口和抽象类分离出来，形成一个单独的Interface Library。如此分解以后，循环引用的问题被解决(见下图)，而且Concerte Library的变化也只需重新编译Facade Library，由于该类库非常简单(可能只有Facade类)，因此也避免了上面提到的编译问题。在不破坏设计框架和实现框架分类的前提下，稍微的复杂度显然能给我们带来更多的好处。