lzl*_*31x 51 data-binding android mvvm android-databinding
我和我的同事都有Web应用程序的MVVM经验,而我们是本机android开发的新手.现在我们对android数据绑定有相反的看法 - 我不喜欢它的粉丝.
我的论点:
他的论点:
我做了一些调查,但关于它的讨论并不多.现在我想收集android数据绑定的优缺点.
讨论的方面包括但不限于:
dan*_*ata 39
我先评论你的论点然后我会陈述我的意见:
1.删除样板代码 - 它将删除一些它只会移动一些xml或它将需要额外的类.因此,您必须小心并平衡数据绑定的使用.
2.更强的可读性 - 取决于你是一个新的开发人员,然后你可能会发现它很容易学习它,但如果你以前在Android上工作,你将需要额外的时间来学习它.
3.Powerful - 代码具有更强大的功能,您可以在代码中实现您喜欢的任何内容.想想这样,使用数据绑定实现的所有内容都具有等效的代码(可能更长,编写更多代码),但反转无效.
4.比快速findViewById- 比较这两者之间的速度,在我看来是没用的,你永远不会注意到差异,如果你看到一些差异,那么其中一个实施是错误的.
5.Auto生成的类 - 它确实会增加应用程序的大小,但是只有你有大量的它才会重要.确实,在android开发网站上,他们声明使用创建自动生成代码的库或者annotations会产生额外代码是很糟糕的.
6.难以调试 - 取决于你可以使用的可读性,对于某些问题,heck调试很难,并且通过调试而不是使用不同的库,你会变得更好.
所以这纯粹是我的观点,我开发了许多使用不同库和不同方法的应用程序,它们都有优点和缺点,但我学到了:平衡一切,不要使用大量的库,不要浪费时间实现已经实现并且运行良好的东西,不要"解耦所有东西",不要"耦合"一切,不要只使用代码,不要试图"生成"一切.
我认为这是非常错误的,你可能会得到一个错误的想法,如果你要求某些图书馆/实施的"利弊",因为通常它不会是公正的,你会得到很多来自使用图书馆以特定的方式运作,其他人会给你利弊,因为他们使用不同的,它没有用.
总而言之,我认为您应该检查一下库可以为您做什么以及哪些不能为您做什么,并确定它是否适合您的设置.换句话说,你应该决定图书馆是否适合你而不是其他人;).
更新 - 2018年8月8日
首先,我仍然坚持我的初步结论,平衡是这种情况下的关键,但就我而言,数据绑定加快了一点开发过程并改进了它.以下是您应该考虑的一些新观点.
测试用户界面 - 通过数据绑定可以更轻松地测试用户界面,但数据绑定对于它来说还不够,还需要一个好的架构,使用谷歌建议的架构将显示数据绑定的实际功能.
从我原来的答案中为第2点和第5点提供了最明显的变化.在我们决定使用数据绑定后,它更容易阅读代码,最重要的是:我们作为一个团队决定我们将使用数据绑定,之后,我们希望有大部分XML文件中的简单和基本UI设置.
对于调试部分,这里有点棘手,Android Studio在数据绑定的错误和自动完成方面有很多改进,但是在前2-3次发生后你会得到最常见的错误.此外,我已经了解到一个"清洁项目"不时形成,有助于很多.
作为第二个结论(从我原来的帖子),如果你可以和项目截止日期/要求/等允许你尝试数据绑定,那么它值得(除非你做一些非常愚蠢的东西:))).
即使我喜欢 danypata 的回答，我也想将他的一些语句添加/编辑到 android 数据绑定中。
1.删除样板代码- 正如在 danypatas 中写的那样，它删除了一些代码并在其他地方添加了一些代码，比如在布局中。这并不意味着锅炉代码不会减少，因为通常它会减少。
例如，您可能想要创建一个 bindingadapter，它可以为您的 spinner/recyclerview/listview/.. 处理多个自定义数组适配器，但只需要一个简单的适配器。您可能希望在布局中使用适配器，例如
app:myCoolAdaptersData="@{model.mydata}"
现在您可以创建通用适配器并（重新）在所有布局中使用您的 bindingadapter 而不是使用例如：
ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);
这只是一个简单的例子，它在较大的项目中减少了大量的代码。另一个减少代码的示例是，将模型绑定到布局。更新模型的字段值通常也会更新模型（如果它至少是 BaseObservable/ObservableField）。
这意味着您不需要查找所有视图、更新视图、更新模型……
2.更强的可读性- 学习数据绑定所花费的额外时间并不重要。由于布局并没有真正不同，只是将它们包装到布局标记中并将命名空间放在那里，因此它与“常规”布局并没有真正的不同。使用 bindingadapters 和访问布局中的模型可能需要一些时间，但通常您可以从基础知识开始，这些基础知识也易于使用且美观。学习新东西总是需要时间，但在使用数据绑定一段时间后，你会很容易地调整时间。
3.Powerful - 是的，它非常强大。重用现有代码、重用现有绑定适配器更容易，并可能导致生成更多代码，但并非总是如此。例如，您可以在多个类中创建多个适配器而不是创建一个绑定适配器，以后可能很难对其进行“优化”。优化 Bindingadapter 意味着它会随处更新。优化可能会减少“代码行数”，因为无论如何都会减少样板间。
我同意 4. 和 5.
6. 难以调试由于 AS 3.0+ 会输出有用的提示，例如布局中的语法问题（行号和文件），因此很容易调试数据绑定生成的代码。如果您在查找问题时遇到问题，您可能还需要检查生成的代码中是否存在错误。一些库如 dagger 2 或 android 架构库可能会让你感到困惑，因为错误行与真正的“错误”不匹配。这是由于其他注释处理器生成的代码。如果您知道那些注释处理器可能会遇到数据绑定错误输出的问题，那么您可以轻松解决这个问题。
7. 单元测试这可能就像你不使用数据绑定通过使用 executePendingBindings。
8. 可读性没有数据绑定的可读性可能会更好。由于您将一些业务逻辑放入布局中，将一些放入实际代码中，因此可能会导致意大利面条式代码。另一个问题是，如果“布局设计师”不知道可以使用哪个参数，则在布局中使用 lambda 可能会非常混乱。
另一个非常大的问题是 bindingadapter 可以无处不在。使用 BindingAdapter 注释生成代码。这意味着在您的布局中使用它可能会导致无法找到正确的代码。如果要更新 bindingadapter，则需要“找到”它。
什么时候应该使用什么？对于较大的项目，将数据绑定与 mvvm 或 mvp 模式一起使用是一个非常好的主意。这是一个非常干净的解决方案，并且非常容易扩展。如果您只想创建一个简单的小型应用程序，则可以使用没有数据绑定的 MVC 模式。如果您已有可从其他项目使用的通用绑定适配器，您可能希望使用数据绑定，因为它易于重用此代码。