Android app按三层架构+MVC整理(重构)代码可行吗
项目是别人写的,领导让我们重构。虽然有MVP和MVVM,但领导用了三层架构(表现层,业务层,数据访问层)+MVC这么多年,敲定还是按这种体系。领导负责定基调,具体的实施当然由我们这些人做。于是大体上会把acvitivy/fragment拆一下,主要做controller控制器,view会从里面拆出来单独成一部分,通过接口与activity交互。然后加上实体等部分。大致形成v
·
项目是别人写的,领导让我们重构。
虽然有MVP和MVVM,但领导用了三层架构(表现层,业务层,数据访问层)+MVC这么多年,敲定还是按这种体系。领导负责定基调,具体的实施当然由我们这些人做。
于是大体上会把acvitivy/fragment拆一下,主要做controller控制器,view会从里面拆出来单独成一部分,通过接口与activity交互。然后加上实体等部分。
大致形成view(视图),controller(控制器),bll(业务逻辑层),dal(数据访问层),entity(实体)几个部分。
小弟的水平十分有限。基本上项目做了,界面实现了,也就实现了。架构和设计模式一窍不通。所以来请教一下。
基本上应用的界面不多。几个一级页面是fragment,退出前不会销毁。
每个页面倒是有一定程度的业务逻辑。
首先想到的就是工厂模式。一个总的业务工厂,然后根据控制器的需求创建不同的业务类。
数据访问层可能也是类似去做。
然后想了想,既然几个一级fragment都是不销毁的。
业务逻辑的工厂类一旦创建具体的业务类就保存起来,以备调用时不用重新创建。
然后这样一想,好多东西都没有被回收。
再加上数据访问层也用工厂。似乎大部分的对象创建后都一直留着。
完全不懂架构设计,请教前辈有没有好点的解决方式?
对于android拆成view(视图),controller(控制器),bll(业务逻辑层),dal(数据访问层),entity(实体)有什么看法?
虽然有MVP和MVVM,但领导用了三层架构(表现层,业务层,数据访问层)+MVC这么多年,敲定还是按这种体系。领导负责定基调,具体的实施当然由我们这些人做。
于是大体上会把acvitivy/fragment拆一下,主要做controller控制器,view会从里面拆出来单独成一部分,通过接口与activity交互。然后加上实体等部分。
大致形成view(视图),controller(控制器),bll(业务逻辑层),dal(数据访问层),entity(实体)几个部分。
小弟的水平十分有限。基本上项目做了,界面实现了,也就实现了。架构和设计模式一窍不通。所以来请教一下。
基本上应用的界面不多。几个一级页面是fragment,退出前不会销毁。
每个页面倒是有一定程度的业务逻辑。
首先想到的就是工厂模式。一个总的业务工厂,然后根据控制器的需求创建不同的业务类。
数据访问层可能也是类似去做。
然后想了想,既然几个一级fragment都是不销毁的。
业务逻辑的工厂类一旦创建具体的业务类就保存起来,以备调用时不用重新创建。
然后这样一想,好多东西都没有被回收。
再加上数据访问层也用工厂。似乎大部分的对象创建后都一直留着。
完全不懂架构设计,请教前辈有没有好点的解决方式?
对于android拆成view(视图),controller(控制器),bll(业务逻辑层),dal(数据访问层),entity(实体)有什么看法?
更多推荐


所有评论(0)