简单的架构模式

（1）分层开发

分层开发的要点是将不同类型的行为封装到不同层中。它的原则应该是，同一层下的行为不应该有依赖关系，底层行为依赖于上层行为，只有相邻层能够有直接依赖的关系。

它的好处在于，同层内容易于扩展（因为这些行为其实都应该抽象成接口），对于同层的其他行为而言，并不会感觉多了一个行为；上层内容只依赖下层接口，那么下层的增加减少行为类也就不会有多大的影响，这就起到了高内聚，低耦合的效果。

但是缺点是，在一些情况下，层与层之间的关系是并列的，但又互相有联系，此时分层的优势就不能最大程度的体现了。

（2）MVC模型

MVC模型的要点是职责分离，我感觉这是一种宏观上的分层。

它将职责分为三个：视图、控制、模型。这样的好处就是，使用控制层，将视图和模型联系，就可以形成视图:模型=n:1的关系，彼此之间能够独立存在，视图可以在运行时断开和连接。

（3）C/S模式

简单而言就是，服务器需要持续监听客户端，客户端要时不时汇报一下当前状态。

好处就是，服务器开启的服务客户端可以请求，服务器局部关闭服务并不会影响正常运行。

但缺点是，服务器往往只有一个接收请求的单线程（在之前写的聊天室中可以发现这一点），所以会有效率低下的弊端。

（4）事件总线模式

我感觉这是设计模式中的观察者模式，因为它的解释是，在运行时，一个信息源负责消息更新，然后通知给正在监听此信息源的事件监听器，在此过程中，我们通过事件可以添加或移除消息源中的事件监听器，这样的话下一次通知的对象也会随之改变。

它的好处在于动态通知不同行为，据网上所说，它对高度的分布式应用程序很有效。

但是，由于消息在一个信息源产生，所以可能在处理信息上有所差异（行为方式不同）。

（5）除此之外

除了以上的四种外，还有一些眼熟或者不眼熟的模式，但是还没有接触太多，此时就只留一个印象，写在笔记中，以后想起来的时候也方便查阅。

当然，目前而言，这些架构模式仅仅是理论层次上的，实际应用还需要多多练习。