App架构设计

App架构设计

1. 架构的设计原则

   1、开闭原则（Open Close Principle）

开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2、里氏代换原则（Liskov Substitution Principle）

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科

3、依赖倒转原则（Dependence Inversion Principle）

这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。

5、迪米特法则（最少知道原则）（Demeter Principle）

为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则（Composite Reuse Principle）

原则是尽量使用合成/聚合的方式，而不是使用继承。

一款优秀的架构软件架构都应该符合这几条规则。

开发一款软件需要的步骤

1. 需求分析，尽可能的理清楚开发需
2. 模块化，弄清楚项目需要多少个模块
3. 层次化，确实采取什么模式如 MVC
4. 抽象化，面向接口编程

没有规划的App结构

在Activity，Fragment 等界面里面 直接调用 NetWorkUtils，DBUtils 完成接口访问。
问题:
1. Activity，Fragment 代码混乱，冗肿，无法复用
2. 难维护
3. 难扩展
4. 更容易造成Bug

像这样的 App 架构，可以说是没有架构。 一旦界面 （需求）更改比较大，基本上要重写一个，原来写的代码无法使用，很多工作都得重来。软件业务也混杂在 Activity，Fragment里面。
开发成本，时间，造成浪费。而且但app复杂到一定程度后会感觉到越开发越困难，越烦。

有必要给app 设计一个框架

我们这里用了 MVC 来划分 我们的软件架构。

1. Views 层 负责现实，处理页面逻辑 ，交互。严格意义来讲是View&Controller，控制页面的调转等。
2. BLL 层 负责业务逻辑处理，不应该持有View的对象，不像MVP P里面是持有View的对象，BLL 层负责数据处理，校验等，如用户名是否为空，排序，筛选，封装数据等。
3. DAL 负责数据访问，存储，下载。负责访问接口，查询数据库，提供数据给BLL层，对数据不进行处理校验，只负责拉取数据。

这是一个架构的模本例子:
使用了：

View 层模块是 app:

BLL 层模块是 serverapibll , imsdkbll

DAL 层模块是 serverapidal ,imsdkdal

utils 是工具包， 可以供 app ,bll ,adl 层使用。

network ，是网络访问模块，供 DAL 层使用， 如果有数据库访问
database 也是 属于 ＤＡＬ层的模块。

例子中集成了　一个云信的，ｄｅｍｏ。有限判断逻辑写在了Activity中，这是不对的。这些逻辑都应该写在BLL中。

项目分这么多模块有个好处，这些模块可以共用，可以用在多个APP中，也方便管理。但是编译速度会慢一点。

项目代码及结构设计图:
(AppDesign.vsdx , AppDesign.png)
https://git.oschina.net/linving/cloud_im.git