![[泣不成声]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_40.348108b.png)
![[呲牙]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_2.cd1e2bd.png)
#青训营 x 字节后端训练营#
1.5 无处安放的业务逻辑
关于业务逻辑其实是一个很笼统的概念，甚至可以将任意一行代码称之为业务逻辑，如此宽泛的概念我们该如何去理解？我先大致将它分为两个方面：
界面交互逻辑：视图层的交互逻辑，比如手势控制、吸顶悬浮等等都是根据业务需要实现的，所以严格来说这部分也属于业务逻辑。但这部分业务逻辑一般在视图层实现。
数据逻辑：这部分是大家常说的业务逻辑，属于强业务逻辑，比如根据不同用户类型获取不同数据、展示不同界面，加上Data Mapper一系列操作其实就是给后端兜底，帮他们补全剩余逻辑而已。为了方便大家理解下文我将数据逻辑统称为业务逻辑。
前面我们说到，Android开发应该具备数据层跟视图层，那业务逻辑放在哪一层比较合适呢？比如MVVM模式下大家都说将业务逻辑放到ViewModel处理，这么说也没有太大的问题，但如果一个界面足够复杂那对应的ViewModel代码可能会有成百上千行，看起来会很臃肿可读性也非常差。最重要的一点这些业务很难编写单元测试用例。
关于业务逻辑我建议单独写一个use case处理。
use case通常放在ViewModel/Presenter与数据层之间，业务逻辑以及Data Mapper都应该放在use case中，每一个行为对应一个use case。这样就解决了ViewModel/Presenter臃肿的问题，同时更方便编写测试用例。
注意点：
好的设计都是特定场景解决特定问题，过度设计不仅解决不了任何问题反而会增加开发成本。以我目前经验来看Android开发至少一半的场景都很简单：请求-->拿数据-->渲染视图最多再加个Data Mapper，流程很单一并且后期改动的可能也不太大，这种情况就没必要写一个use case，Data Mapper扔到数据层即可。
1.5 无处安放的业务逻辑
关于业务逻辑其实是一个很笼统的概念，甚至可以将任意一行代码称之为业务逻辑，如此宽泛的概念我们该如何去理解？我先大致将它分为两个方面：
界面交互逻辑：视图层的交互逻辑，比如手势控制、吸顶悬浮等等都是根据业务需要实现的，所以严格来说这部分也属于业务逻辑。但这部分业务逻辑一般在视图层实现。
数据逻辑：这部分是大家常说的业务逻辑，属于强业务逻辑，比如根据不同用户类型获取不同数据、展示不同界面，加上Data Mapper一系列操作其实就是给后端兜底，帮他们补全剩余逻辑而已。为了方便大家理解下文我将数据逻辑统称为业务逻辑。
前面我们说到，Android开发应该具备数据层跟视图层，那业务逻辑放在哪一层比较合适呢？比如MVVM模式下大家都说将业务逻辑放到ViewModel处理，这么说也没有太大的问题，但如果一个界面足够复杂那对应的ViewModel代码可能会有成百上千行，看起来会很臃肿可读性也非常差。最重要的一点这些业务很难编写单元测试用例。
关于业务逻辑我建议单独写一个use case处理。
use case通常放在ViewModel/Presenter与数据层之间，业务逻辑以及Data Mapper都应该放在use case中，每一个行为对应一个use case。这样就解决了ViewModel/Presenter臃肿的问题，同时更方便编写测试用例。
注意点：
好的设计都是特定场景解决特定问题，过度设计不仅解决不了任何问题反而会增加开发成本。以我目前经验来看Android开发至少一半的场景都很简单：请求-->拿数据-->渲染视图最多再加个Data Mapper，流程很单一并且后期改动的可能也不太大，这种情况就没必要写一个use case，Data Mapper扔到数据层即可。
展开
评论
点赞