业务逻辑？呵呵，许多前端新人很困惑这个话题。当他们在面试当中被问到“这个业务逻辑你是如何处理的”的时候，他们经常会不知如何回答。 什么是业务逻辑？...其实一句话就能说的清，“客户想干什么”，这就是业务逻辑。许多同学搞不清业务逻辑，其实就是没搞清你的客户想要做什么。 所以有那么句话说，业务逻辑是由客户的脑洞来决定的。哈哈哈。 <!...这叫正常的很有逻辑。 那，为什么业务逻辑需要分析呢？ 刚才我们说了，业务逻辑是由客户的需求决定的。那么客户的需求通常是不连贯的，是跳跃性的，也就是很可能是非逻辑的，并且是经常会变化的。...例如，刚才那个，也许客户的想法是，我要先看到热菜是什么样？再来决定我要不要买这个菜！觉得很不可理喻吧？这个需求是倒着的！！其实在日常开发中很多这种情况。...所以我们就要分析、理清，让这个不可能理喻的需求，变成可理喻、可实现的需求。 这就是开发当中的业务逻辑。 所以说，需要理解客户。不管你用什么语言写代码。
前言 只要你掌握了基础知识，要想构建一个完整的 Android App 并不难，但是想要写出一个可维护的 App 就是另一回事了，这时候就必须让你自己的代码足够健壮，就需要避免把所有业务逻辑代码都放在...这里有一个重要的概念：View 仅仅处理用户的即时交互。什么意思呢？不要把业务逻辑比如数据库操作相关的业务放在 Activities 或 Fragments 中。...ViewModel ViewModel 就像 View 和业务逻辑之间的粘合剂，它负责从 Repository 获取数据并提供给 View。...Model Model 就是你放置所有特定业务代码的地方，虽然从技术上讲，ViewModel 和 Model 之间存在一个以 Repository 形式存在的中间步骤，你可以将 Repository 中的所有内容视为远离用户界面的一组类...，它并不关心这些 —— 这是 Repository 应该处理的业务逻辑。
Repository 简介 什么是 Repository ？ Repository 类抽象出对多个数据源的访问。存储库不是体系结构组件库的一部分，但是建议的代码分离和体系结构的最佳实践。...在最常见的示例中，Repository 实现了用于决定是从网络获取数据还是使用在本地数据库中缓存的结果的逻辑，既避免了 ViewModel 和数据的直接交互又统一了单一真实数据源的逻辑 Repository...中追加如下内容，转换为 AndroidX 项目 android.enableJetifier=true android.useAndroidX=true 3、创建 Entity、DAO、Database...// wordDao.insert(word) } } } 4、创建 Repository Repository 作为 ViewModel 与数据操作的中间层，避免了 ViewModel...与数据的直接交互，即方便了 ViewModel 的测试，又能在 Repository 中实现单一真实数据源策略，从而使 ViewModel 更加关注于业务层逻辑 class WordRepository
总得来说，Activity或Fragment中的代码应该尽量精简，尽量将业务逻辑迁移到其它层 通过数据驱动界面 另一个重要原则是您应该通过数据驱动界面（最好是持久性模型）。...UI State是经过ViewModel转换的应用数据。 UI层会向ViewModel发送用户事件通知。 ViewModel会处理用户操作并更新UI State。...[600] 网域层负责封装复杂的业务逻辑，或者由多个ViewModel重复使用的简单业务逻辑。此层是可选的，因为并非所有应用都有这类需求。因此，您应仅在需要时使用该层。...://developer.android.com/jetpack/guide/domain-layer 数据层 数据层主要负责获取与处理数据的逻辑，数据层由多个Repository组成，其中每个Repository...便可获取页面的所有状态，相对 MVVM 减少了不少模板代码 添加状态只需要添加一个属性，降低了ViewModel与View层的通信成本，将业务逻辑集中在ViewModel中，View层只需要订阅状态然后刷新即可
二、Android开发中的架构 具体到Android开发中，开发架构就是描述 视图层、逻辑层、数据层 三者之间的关系和实施： 视图层：用户界面，即界面的展示、以及交互事件的响应。...View，视图层，即xml布局 Controller，控制层，负责业务逻辑。...但在Android中，因为xml布局能力很弱，View的很多操作是在Activity/Fragment中的，而业务逻辑同样也是写在Activity/Fragment中。 ?...业务逻辑抽象成IPresenter接口，由具体的Presenter实现类来完成。逻辑操作完成后调用IView接口方法刷新UI。 MVP 本质是面向接口编程，实现了依赖倒置原则。...View，视图，即Activity/Fragment ViewModel，视图模型，负责业务逻辑。 注意，MVVM这里的ViewModel就是一个名称，可以理解为MVP中的Presenter。
为了方便大家理解下文我将数据逻辑统称为业务逻辑。 前面我们说到，Android开发应该具备数据层跟视图层，那业务逻辑放在哪一层比较合适呢？...比如MVVM模式下大家都说将业务逻辑放到ViewModel处理，这么说也没有太大的问题，但如果一个界面足够复杂那对应的ViewModel代码可能会有成百上千行，看起来会很臃肿可读性也非常差。...use case通常放在ViewModel/Presenter与数据层之间，业务逻辑以及Data Mapper都应该放在use case中，每一个行为对应一个use case。...在当前的Android中可以使用DataBinding实现同样的效果，以Jetpack MVVM为例：ViewModel从Repository拿到数据暂存到ViewModel对应的ObservableFiled...，将请求作为入口，渲染做为出口，在这个流程中尽量不做与当前行为无关的事(这也要求ViewModel,Repository中的函数要符合单一原则)。
经常听一些小伙伴提DataBinding不好用，原因是要在xml中写业务逻辑不好调试，对于这个观点我是持否定态度的。...并不是我同意xml中写业务逻辑这一观点，我觉得碰到问题就得去解决问题，如果解决问题的路上有障碍就尽量扫清障碍，而不是一味的逃避。 如{vm.isShow ?...关于这个问题我在上篇文章Data Mapper章节中描述的很清楚，拿到后端数据转换成本地模型(此过程会编写所有数据相关逻辑)，本地模型与设计图一一对应，不但可以将视图与后段隔离，而且可以解决xml中编写业务逻辑的问题...UI逻辑的处理 Repository(远程): 代表远程仓库，从Repository取需要的数据 ViewModel: Repository取出的数据需暂存到ViewModel，同时将数据映射到视图层...如果你们的后端比较善变我建议引入Data Mapper的概念～如果你经常和同事开发同一个界面，可以试图将每一条业务逻辑封装到use case中，这样大概率可以解决Git冲突的问题..等等等等，总之只要能实实在在
前面我们说过，Model 层主要管理业务模型的数据和行为，它既保存程序的数据，也定义了处理该数据的逻辑，所以 Model = 数据 + 业务逻辑。...因此，处理业务逻辑属于 Model 的职责，而非 Controller。从数据的维度来说，可以细分为数据的定义、数据的存储、数据的获取。...ViewModel Model 封装了业务逻辑和数据，管理的是业务模型。...，肯定还需要做一些数据转换，比如，需要将时间戳转换为「yyyy-MM-dd HH:mm:ss」格式的时间，paid 转换为「已付款」，金额前面再加个￥符号，数量前面加多个乘号。...getUserNameFromCache() 方法的逻辑更简单，就直接从缓存中读取并返回。 LoginViewModel 接着，再来聊聊 ViewModel，这个就很关键了。
对于前端我觉得可以适当引入Data Mapper，将后端数据转换成本地模型，本地模型只与设计图对应，将后端业务与视图完全隔离。...为了方便大家理解下文我将数据逻辑统称为业务逻辑。 前面我们说到，Android开发应该具备数据层跟视图层，那业务逻辑放在哪一层比较合适呢？...比如MVVM模式下大家都说将业务逻辑放到ViewModel处理，这么说也没有太大的问题，但如果一个界面足够复杂那对应的ViewModel代码可能会有成百上千行，看起来会很臃肿可读性也非常差。...在当前的Android中可以使用DataBinding实现同样的效果，以Jetpack MVVM为例：ViewModel从Repository拿到数据暂存到ViewModel对应的ObservableFiled...(这也要求ViewModel,Repository中的函数要符合单一原则)。
引言 在Android开发中，数据的管理是一个至关重要的问题。随着应用复杂度的增加，我们需要一种能够有效管理数据和处理UI相关逻辑的机制。Android架构组件中的ViewModel应运而生。...在Android中，ViewModel通常用于存储和管理与UI相关的数据，以确保这些数据在屏幕旋转或配置更改等情况下不会丢失。 原理解析 ViewModel的原理是基于ViewModelStore类。...它的存在是为了解决以下问题： 生命周期一致性：在Android开发中，我们经常遇到配置更改（如屏幕旋转）导致Activity或Fragment被销毁并重新创建的情况。...将ViewModel的职责限制在处理UI相关的逻辑，不要包含过多的业务逻辑。 谨慎使用SavedStateHandle，避免将大量数据存储在其中导致性能问题。...结语 通过深入理解ViewModel的原理和高级运用，我们可以更好地利用这一强大的架构组件。ViewModel的设计模式和生命周期感知使其成为Android开发中不可或缺的一部分。
这篇文章其实是大健康行业直销系统的番外篇，主要给大家讲讲如何在领域逻辑中，有效的处理业务逻辑条件判断的最佳实践问题。 大家都知道，聚合根、实体和值对象这些领域对象都自身处理自己的业务逻辑。...在业务处理过程中，通常会有一些条件判断，当满足这些条件时，会进行不同的后续处理。...在传统的实现中，可以通过If Else条件语句进行判断，但If Else语句在复杂领域中来检查是否满足一些业务条件存在以下的问题： 1. 无法很好的显示表达业务条件本身。 2. ...无法对多个条件在不同需要的地方进行灵活的组合。 为了更好的组织业务逻辑中关于业务条件的判断，最佳实践方式是将业务条件拆分得足够细，并用语义化的方式表示。...举个例子：酒店业务中，房间领域对象会处理预定房间的领域逻辑和退房的领域逻辑，在预定房间时，我们需要保证房间没有被其他人预定并且房间没有正在维护这两个业务条件同时满足；在退房时，我们需要保证房间里没有物品损坏或已经进行了损坏赔偿这两个业务条件中的任意一个
( 导入依赖 | 定义 Entity 实体类 | 定义 Dao 数据库访问对象接口 | 定义数据库实例类 ) 中 , 实现了 使用 Room 框架访问 Android 中的 SQLite 数据库的操作...监听器回调中 更新 View 视图 ; View 视图层 : Activity / Fragment 负责视图显示的 系统组件 , 负责维护 Android 视图组件 , 显示的数据由 ViewModel...) } 同时 , 需要 在 ViewModel 中维护 数据库 的 增删改查 的对应函数 , 通过调用 Repository 成员边来那个实现对数据库的操作 , 查询函数 的返回值是 LiveData...ViewModel 使用要点 在 Activity 组件中 , 通过调用 ViewModel 视图模型获取 数据库中的数据 , ViewModel 调用 Repository 层的增删改查方法 , Repository...ColumnInfo(name = "age", typeAffinity = ColumnInfo.INTEGER) var age: Int = 0 /** * 有些属性用于做业务逻辑
在xml中写表达式逻辑，出错了debug不了啊，逻辑写在xml里面的话 xml 就承担了 Presenter/ViewModel 的职责 变得混乱了啊。”...这里对 Jetpack AAC 及 MVVM ，做一些 补充 和 说明： 一、ViewModel 和 View 职责分离，ViewModel中处理业务逻辑，View 仅展示数据及传递事件 二、ViewModel...六、ViewModel 和 Repository 之间，建议 使用 LiveData 进行通信，就像 View 和 ViewModel 之间那样 使用回调的话，可能会有内存泄漏的风险。...并且在ViewModel中 使用 Transformations.switchMap 把 生命周期信息 传递到 Repository 的 LiveData 中。...LivaData 的字段 九、XML 中尽量 不使用逻辑表达式，把逻辑放在 ViewModel 中，控件绑定终态数据 五、总结 本篇 重点讲了 DataBinding 的重新认知：DataBinding
✅将Activity和Fragment中的逻辑保持在最低限度 View references in ViewModels 视图模型与Activity或Fragment有不同的作用域。...Observer Pattern img 在Android中设计表现层的一个非常方便的方法是让View（Activity或Fragment）观察（订阅）ViewModel的变化。...如果你的ViewModel容纳了太多的代码或者有太多的责任，可以考虑。 将一些逻辑转移到与ViewModel相同范围的presenter中。...如果repository持有对ViewModel中回调的引用，ViewModel将被暂时泄露。 img 如果ViewModel是轻量级的，或者操作被保证快速完成，这种泄漏就不是什么大问题。...✅考虑边缘情况、泄漏以及长期运行的操作会如何影响你架构中的实例。 ❌ 不要在ViewModel中放置对保存清洁状态或与数据有关的逻辑。你从ViewModel进行的任何调用都可能是最后一次。
应用层、业务逻辑层及数据访问层。mvc的思想其实也一样，都是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。...逻辑中与界面对应的id不变化则代码不用修改，大大增强了代码的可维护性。 控制层(Controller) Android的控制层主要就是Activity层。...项目开发中，UI是容易变化的，且是多样的，一样的数据会有N种显示方式；业务逻辑也是比较容易变化的。...（回调）的方式回到ViewModel中，由于ViewModel与View的双向绑定，使得界面得以实时更新。...使用RXJAVA对数据流进行处理，并且通过Repository进行数据的集中管理，通过协议类XXXContract来对View和Presenter的接口进行内部继承，在presenter的实现类中，可以对
应用层、业务逻辑层及数据访问层。mvc的思想其实也一样，都是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。...逻辑中与界面对应的id不变化则代码不用修改，大大增强了代码的可维护性。 控制层(Controller) Android的控制层主要就是Activity层。...项目开发中，UI是容易变化的，且是多样的，一样的数据会有N种显示方式；业务逻辑也是比较容易变化的。...（回调）的方式回到ViewModel中，由于ViewModel与View的双向绑定，使得界面得以实时更新。...，并且通过Repository进行数据的集中管理，通过协议类XXXContract来对View和Presenter的接口进行内部继承，在presenter的实现类中，可以对Model数据进行操作。
导读 实仓和虚仓的概念是针对系统开发本身而言的。简单来说，核算成本的仓库可以称之为实仓，不核算成本的可称之为虚仓。虚仓在系统中主要过渡的作用。...在中台系统中，虚仓即等于库存的分配池，在同个仓库组中单个商品的库存，实仓库存之和=虚仓库存之和。 那么在商城中台库存管理中，实仓与虚仓的业务逻辑该怎么设计呢？...在这里需要插入说明“移仓”的必要性，即移仓可以对同个仓库组中的虚仓进行库存调整。...比如订单购买商品a，实仓a和实仓b都有商品a的库存，订单适配到虚仓a，实仓a和实仓b都有可能发货，中台需要有算法会适配最优（距离最优，物流费用最优等）的实仓发货。...四、货物库存的流通 对于货物流通而言，中台的实仓=发货门店，采购动作在门店系统（大多数为新零售系统）。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
云直播
实时音视频
