Android中使用Data Binding有哪些缺点？是否违反关注点分离原则？

数据直接绑定到XML布局的缺点 #

• 调试成本极高：XML中的绑定逻辑报错时，Android Studio给出的堆栈信息非常模糊，通常只会提示绑定失败，不会精准定位到具体是哪一行绑定表达式出错，比如变量名拼写错误、数组索引越界这类问题，排查耗时是纯代码逻辑的数倍，也无法像普通代码一样打断点逐行调试。
• 逻辑分散易漏改：业务逻辑拆分在XML和Kotlin/Java两个位置维护，比如你示例中的日期选中判断逻辑，如果后续要新增时区适配、点击埋点这类需求，你需要同时修改XML绑定逻辑和ViewModel代码，很容易出现漏改的情况。而且XML的语法检查、代码补全能力远弱于原生代码，写绑定表达式的出错概率也更高。
• 逻辑复用性差：XML中写死的绑定逻辑只能在当前布局使用，如果其他页面也需要同样的日期判断、点击处理逻辑，只能复制粘贴代码，无法像ViewModel中封装的方法一样全局复用，迭代时会产生大量冗余代码。
• 存在隐性性能开销：复杂的绑定表达式（比如多层嵌套的三元判断、频繁触发的实时计算逻辑）会让编译器生成大量额外的中间代码，这部分性能损耗很难被排查到，不像原生代码可以直接做性能打点分析。
• 提升团队协作成本：如果团队有明确的分工（比如部分人负责写布局，部分人负责写业务逻辑），负责布局的开发人员不了解业务逻辑，很容易误改绑定表达式导致线上问题。同时代码评审时大家通常会重点检查业务代码变更，很容易遗漏XML中的逻辑变更，留下线上隐患。

对关注点分离原则的影响 #

确实会明显削弱*separation of concerns（关注点分离）*原则。该原则的核心要求是不同职责的代码拆分到独立模块维护，XML布局本身的职责只有定义视图结构、样式和外观，业务逻辑、数据处理逻辑本应该归属ViewModel、Repository层。将数据判断、事件处理逻辑写到XML中，相当于把视图层和逻辑层的职责耦合在一起，后续如果要替换视图实现（比如把示例中的RadioButton改成Chip组件），还需要把原有XML中的逻辑重新迁移一遍，完全违背了分离原则的设计初衷。

内容的提问来源于stack exchange，提问作者Mirian Fonkam