简单记录自己的“架构”搭建经验

	今年年初到现在已经有7个月了，我负责开发了两个独立项目的架构搭建以及核心的研发工作。以下所说的项目都是基于Qt开发。Qt主要是显示界面，核心的后端采用原生C++实现。
	简单说说两个项目吧。
	第一个是一个QA项目：
	原理比较简单。就是给一个输入，经过检验后给个输出。项目的要求是：每一种检查都是一个动态库，采用插件化架构（实际上插件化只是一种设计思维，但其实所有的架构都是一种或几种设计思维的结合后的产物）。
	经过两天的了解后，我开始了人生中第一个插件化架构设计。插件化，即将某一类功能做成一个插件（动态库），采用动态加载的方式在运行时加载在界面上。那么第一个问题就是要先定义一个公共的插件化基类。由于当时开发时间紧迫，我就采用了Qt自带的插件化宏，然后加入自己的业务逻辑，实现了自己的插件化基类。
	由于系统需要考虑异步方式同时进行多项检验。所以，我基于Qt开发了一个自己的线程池和调度线程类。即，没一个检验任务，我都会将其放入子线程中处理，当子线程处理后，再通过信号和槽方式通知主线程。
	插件化基类和线程池调度都做好后，开始实现第一个插件。插件的制作比较简单，插件实现类继承自插件化基类，然后实现本插件的自有逻辑。由于插件中需要使用子线程异步执行一些耗时操作，所以，我再插件化基类中实现了增加子线程任务的接口，这是个基于C++11实现的接口，以后每个插件都可以通过此插件将自己的异步操作在工程的线程池中的线程来完成。原则上工程的所有的插件的异步操作都不能在自定的子线程中操作！
	第一个插件做好后，接着做第二个插件。做好了第二个插件后，产生了一个新问题。那就是如何实现插件间通信。当时，这个问题让我思考了一下午。因为以后其它插件有可能会被其它公司进行二次开发，或者说是其它公司会在我这个架构上进行二次开发插件。那么，我就得设计一个简单且好用的插件间通信的机制。有些时候，人特别容易被自己的固定思维所迷惑，比如一问道类似于进程间通讯，大家都会使用管道或者网络方式进行。但我觉得，这个不利于以后别人进行二次开发，并且我觉得当前工程也还没有到需要使用那么“重”的方式实现通讯的时候。就在自己思考的时候，突然闪过一个想法：何不利用插件化基类，实现一个统一的插件间互访的接口呢？插件间的交互无外乎就是想要知道其它插件的一些信息或需要调用其它插件的一些功能。基于这个业务需求，我在工程的业务调度类中定义了一套机制。在插件化基类中定义一个函数，函数的形参为：来源插件名字、目的地插件名字、void* 入参、void* 出参、错误信息。以后所有的插件都可以通过上述的接口访问其它插件，同时，我可以在业务调度类中实现插件互访的管控。
	好了，一个比较完善的插件化架构基本成型了。毕竟这是自己一个人设计的第一个架构，对自己来说是实现了0到1的过程。在这个过程中，自己解决了很多以前没有想过和遇到过的问题，所以，自己还是蛮自豪的。在这个项目中，我使用的设计模式有：抽象工程模式、克隆模式、组合模式和单例模式。


	现在来说说第二个架构吧。第二个项目由于需要多人同时开发，而且数据层会很重。所以，我采用“MVP”模式。MVP模式相对于“MVC”的开发模式的优势在于：数据层完全与UI层隔离，便于多人协同开发以及后续的维护。架构图如下所示：
	
	在这里插入图片描述

这次的架构设计，我觉得是自己真正意义上的思考多人协同且针对于比较大型项目的开发模式的一次探索。
首先先说下设计思路吧。总共分为3层：UI层、业务层和数据层。UI层只能与业务层通讯，数据层以组合模式加载到业务层。数据层将会定义一个统一的数据层访问接口类。所有的数据层访问都必须通过此类进行访问。业务的处理流程为：UI层事件产生-》AccuBusinessManager单例-》业务层处理业务-》数据层处理数据-》AccuCommandAccess命令单例类-》UI层（或业务层）。UI层只能通过AccuBusinessManager单例来访问业务层。通过这样的设计，使项目的展示层、业务层和数据层充分解耦。
此架构采用的设计模式有：抽象工厂模式、单例模式、命令模式、观察者模式。
通过这两个项目的历练，自己对所谓的软件架构思维开始有了一些真正的探索和积累。
架构设计思维模式生成尚未成功，同志仍需努力啊！以此来时刻提醒及激励自己前行。
这次说的比较糙，相信在接下来的设计中，我会有更多的好的想法与大家交流。这次所述更多的是对自己的一次总结，后续会在提炼更多的精华后，再以更好的描述来与大家共勉。