有可能在Java中为Android实现模型-视图-控制器模式吗?
或者它已经通过活动实现了吗?或者有没有更好的方法来实现Android的MVC模式?
有可能在Java中为Android实现模型-视图-控制器模式吗?
或者它已经通过活动实现了吗?或者有没有更好的方法来实现Android的MVC模式?
当前回答
经过一番搜索,最合理的答案是:
MVC已经在Android中实现了:
View =布局,资源和内置类,如从android.view.View派生的Button。 控制器=活动 模型=实现应用程序逻辑的类
(顺便说一下,这意味着活动中没有应用程序域逻辑。)
对于小型开发人员来说,最合理的做法是遵循这种模式,不要尝试做谷歌决定不做的事情。
PS注意,活动有时会重新启动,所以它不是模型数据的地方(引起重新启动的最简单的方法是从XML中省略android:configChanges="keyboardHidden|orientation",然后转动你的设备)。
EDIT
我们可能会谈论MVC,但它会这样说,FMVC,框架-模型-视图-控制器。框架(Android操作系统)强加了它的组件生命周期和相关事件的想法,在实践中,控制器(活动/服务/BroadcastReceiver)首先负责处理这些框架强加的事件(如onCreate())。是否应该单独处理用户输入?即使应该,你也不能把它分开,用户输入事件也来自Android。
总之,你在Activity/Service/BroadcastReceiver中植入的非android专用代码越少越好。
其他回答
没有普遍唯一的MVC模式。MVC是一个概念,而不是一个可靠的编程框架。你可以在任何平台上实现你自己的MVC。只要你坚持以下基本思想,你就是在实现MVC:
模型:渲染什么 视图:如何渲染 控制器:事件,用户输入
也可以这样考虑:当您为模型编程时,模型不应该担心呈现(或特定于平台的代码)。模型会对视图说,我不在乎你的渲染是Android, iOS还是Windows Phone,这是我需要你渲染的。 视图将只处理特定于平台的呈现代码。
当您使用Mono共享模型以开发跨平台应用程序时,这一点特别有用。
没有一个单一的MVC模式可以遵循。MVC只是或多或少地说明了你不应该将数据和视图混为一谈,例如,视图负责保存数据,或者处理数据的类直接影响视图。
但无论如何,Android处理类和资源的方式,有时你甚至被迫遵循MVC模式。在我看来,更复杂的是那些有时负责视图,但同时又充当控制器的活动。
如果您在XML文件中定义视图和布局,从res文件夹加载资源,并且如果您或多或少地避免在代码中混合这些东西,那么您无论如何都是在遵循MVC模式。
当我们将MVC、MVVM或Presentation Model应用到Android应用中时,我们真正想要的是有一个清晰的结构化项目,更重要的是更容易进行单元测试。
目前,如果没有第三方框架,通常会有大量代码(如addXXListener()、findViewById()等),这不会增加任何业务价值。
更重要的是,你必须运行Android单元测试,而不是正常的JUnit测试,后者需要很长时间才能运行,并且使单元测试有些不切实际。基于这些原因,几年前我们开始了一个开源项目RoboBinding——一个用于Android平台的数据绑定表示模型框架。
RoboBinding帮助您编写更易于阅读、测试和维护的UI代码。RoboBinding消除了对addXXListener等不必要代码的需求,并将UI逻辑转移到表示模型(Presentation Model),这是一个POJO,可以通过正常的JUnit测试进行测试。RoboBinding本身带有300多个JUnit测试,以确保其质量。
我看到很多人说MVC已经在Android中实现了,但这不是真的。Android默认不遵循MVC。
因为我不谷歌将永远强制MVC实现像iPhone的限制,但它取决于开发人员的模式或技术,他们想在他们的项目,在小或简单的应用程序使用MVC是不需要的,但随着应用程序的增长,变得复杂,并需要修改其代码在以后的几年,然后有一个MVC模式在Android的需求。
它提供了一种修改代码的简单方法,还有助于减少问题。 如果你想在Android上实现MVC,那么按照下面给出的链接,在你的项目中享受MVC实现。
http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/
但是现在,我认为MVP和Android架构模式是开发人员应该使用的干净和健壮的Android应用程序的最佳选择之一。
令人惊讶的是,这里没有一个帖子回答这个问题。它们要么太笼统,模糊,不正确,要么没有解决在android中的实现。
在MVC中,View层只知道如何显示用户界面(UI)。如果需要任何数据,则从Model层获取。但是视图并不直接要求模型去查找数据,它是通过控制器来做的。因此控制器调用模型为视图提供所需的数据。一旦数据准备好了,控制器就通知视图,可以从模型中获取数据了。现在视图可以从模型中获取数据。
这个流程可以总结如下:
值得注意的是,视图可以通过控制器(也称为被动MVC)了解模型中数据的可用性,或者通过向模型注册可观察对象来观察模型中的数据,这就是活动MVC。
在实现部分,首先想到的是视图应该使用什么android组件?活动还是片段?
答案是没有关系,两者都可以使用。View应该能够在设备上呈现用户界面(UI),并响应用户与UI的交互。Activity和Fragment都为此提供了所需的方法。
在本文使用的示例应用程序中,我使用了Activity作为视图层,但也可以使用Fragment。
完整的示例应用程序可以在我的GitHub repo的“mvc”分支中找到。
我还通过一个例子说明了在android中使用MVC架构的利弊。
对于那些感兴趣的人,我已经开始了一系列关于android应用程序架构的文章,在这里我比较了不同的架构,即MVC, MVP, MVVM,通过一个完整的工作应用程序开发android应用程序。