Explorando un diseño de arquitectura de modelo MVP más adecuado

http://www.kuqin.com/shuoit/20150814/347567.html

Respecto a MVP y android, tengo que decir que este blog ha llegado muy tarde. Quería escribir este blog hace mucho tiempo. Siempre he sido un holgazán, así que no voy a poner excusas para ser holgazán tanto tiempo. Aunque este artículo salió relativamente tarde, pero con algunos programadores y amigos con los que me he puesto en contacto, todo el mundo acaba de empezar a oír hablar de mvp y no se ha aplicado realmente al proyecto.

A finales de 2014, había cada vez más pensamientos sobre la arquitectura de Android en los principales foros y blogs de Android. Le he estado prestando atención. También comencé a imitar y escribir a finales de 2014. De hecho, mvp no es una nueva arquitectura. Todos ellos son desarrolladores ganadores que han estado haciendo aplicaciones en modo cs durante muchos años, y los desarrolladores de wpf han roto cosas. No es necesario decir nada sobre el concepto de mvp, todo el mundo debería haberlo leído muchas veces y hablar de ello es una tontería.

Así que ahora veamos qué patrón de diseño usaban todos antes de que no estuviéramos expuestos a mvp. Al principio, aunque a mucha gente le gusta decir que su proyecto es MVC, pero de nuevo, qué, dónde, por qué. ¿Qué es MVC, dónde está el controlador en su proyecto, dónde está la vista y por qué necesita usar el patrón de diseño MVC?

El método de cuestionamiento de 3w que a todo el mundo le gusta usar en varios libros de la historia de la programación. ¿Lo has visto? Esta vez también instalé una buena B, jajaja.

1.¿que es MVC?
Mvc es un patrón de diseño. La mayoría de los proyectos web adoptan la arquitectura de patrones de diseño de mvc, thinkphp, asp.net y el último motor razor. Casi todo el mundo puede decir con mucha claridad sobre la relación de CV detallada, por lo que no es necesario entrar en detalles.
2. ¿Dónde está mvc en tu proyecto, explícame?
Éste. . . La mayoría de la gente responde así: el fragmento de actividad es la vista, y el modelo es el javabean analizado por mi json, ¿verdad? Pero ¿qué pasa con el controlador? wocao, parece que no hay controlador.
3. ¿Por qué debería utilizar el patrón de diseño mvc?
La gente común no puede decir esta pregunta claramente, y mucha gente la responde. Esto es necesario para el proyecto. Esta es la especificación del código y demás. Es inútil. De todos modos, él no pensó que fuera correcto. Esta pregunta generalmente se reduce al aprendizaje y la aplicación de patrones de diseño. Después de usar algunos patrones de diseño y compararlos, sabrá por qué se necesitan patrones de diseño, por qué se utilizan patrones de diseño y cuál es el significado de los patrones de diseño. Solo una frase: para reducir el grado de acoplamiento de códigos. Lo que aumenta la legibilidad depende de su estilo de código habitual. Los patrones de diseño mejorarán un poco la legibilidad, pero este puede no ser el significado principal de existencia.


Bueno, la cuestión de las 3W terminó.




Mi resumen es: hace 14 años, la mayor parte del desarrollo de Android usaba su propio MVC, pero la mayoría de las personas no podían encontrar el controlador, porque el controlador y la vista estaban juntos, desde dos aspectos, este tipo de código. Desventajas:
1. Este no es un modo MVC real
2. El propósito del modo de diseño es desacoplar, por lo que definitivamente advertirá sobre el acoplamiento de código.

En thinkphp, cada solicitud es una acción, y cada acción finalmente apunta a un controlador, pero no hay solicitud en Android. Hay acciones en Android, pero el concepto de acción y acción web
son dos conceptos. En el código fuente de Android, todavía hay algunos mvc, como el adaptador es una especie de controlador.
Ver es actuar, fragmentar, modelar, así que no hace falta decirlo.
Y la arquitectura que usaste antes de 2014 es así, solo unas pocas BaseActivity, BaseFrag, así, este es el modelo de fábrica.

Pregunte cómo Para la propia API de Android y el ciclo de vida de act, ¿es realmente apropiado que usemos mvc? No es adecuado, para ser exactos, entonces, ¿qué patrones de diseño son más adecuados para el desarrollo del lado del cliente? Es mvvm, mvp es adecuado. Consulte el siguiente párrafo: el

tema vuelve a la pregunta "POR QUÉ", ¿por qué queremos utilizar patrones de diseño? ¿Es para fingir ser B? No, estamos para reducir el acoplamiento de códigos. En resumen, podemos conseguir: No importa lo que use el patrón de diseño, siempre y cuando te convenga, no olvides tus intenciones originales de fingir, jajaja, usa un poco de vocabulario. . . Es decir, ya sea que use MVC, MVP, MVVM o una versión optimizada de mvvm, o una versión optimizada de MVP, el propósito del desacoplamiento se logra y el tiempo de desarrollo se ahorra al máximo. Es como la recomendación oficial de Google de renunciar al método getter setter, pero acceder directamente al campo a través del atributo point. Usar el método getter setter es un poco más lento que usar el atributo point para obtener el campo. Aunque es solo un poco, el ciclo se repetirá muchas veces. Y la velocidad de unos segundos se ve afectada. Renuncia al método de escritura java original y usa el método android para escribir el código. Suéltalo, el tiempo de la CPU siempre es más importante que tus hábitos de código.


Volviendo al título del artículo, hablemos de MVP. Ya hemos tenido suficiente de escribir la vista y el controlador juntos. Algunas páginas son muy grandes. Escribí una página. La empresa no tiene un administrador de producto. La página está determinada completamente por la interfaz de usuario. Joder, tengo que sentarme en la misma página de WeChat Pay, Alipay Payment y otros juicios complicados, levantar al cliente de pago para finalizar el proceso, devolver la llamada y hay algunos canales de devolución de llamada, etc., y devoluciones de llamada. Juicio de estado, mierda, solo estos, el código es lo suficientemente agotador, hay otros juicios de visualización de datos, muchas solicitudes de red, demasiados códigos y demasiado complicado, cierto, caocaocaocao.
Por lo tanto, mvp es mejor. Para el patrón y la estructura del código estándar de mvp específico, vaya a otros blogs por su cuenta. Mi blog no quiere extraer algunos conceptos que otros blogs han mencionado muchas veces, y la relación entre el presentador de vista no quiere que se repita. Esto solo puede aumentar La cantidad de palabras en mi blog es solo.

Entonces, la pregunta es, ¿hay alguna desventaja en mvp? 
Si eres un león de asedio, debes ser objetivo cuando miras las cosas. Si eres un programador, no necesitas ser objetivo. No creas que la gente lo admira, pero lo adoras. Debes enfrentar las deficiencias de esto. La forma más estandarizada de escribir mvp es problemática. Después de escribir docenas de páginas de aplicaciones mvp estandarizadas, todavía encuentro este producto muy problemático. Aunque la estructura del código es muy clara, el tiempo de desarrollo es demasiado largo y estoy cansado.
Resumen: La ventaja de mvp es aclarar la organización del código, pero la desventaja es reducir la eficiencia del desarrollo.
En términos de cómo entender la calidad de la capacidad de programación, mi comprensión de la programación es resolver problemas, y la velocidad y elegancia de la resolución de problemas representan la capacidad de programación de una persona.


¿Cómo garantizar que la estructura del código sea clara sin reducir la velocidad de desarrollo? ¿Recuerda cuál de los patrones de diseño que hemos aprendido y utilizado antes es para acelerar la eficiencia del desarrollo, y son adecuados para este tipo de página? Parece que el modelo de fábrica es así. El modelo de fábrica es como una fábrica. La eficiencia de producción es tan alta y tan rápida que no puedes pensar en ello. Pero parece que la escritura estándar de mvp no está bien aplicada. La opinión de caocaocao y android es que act es diferente de otras plataformas. No puedes controlar cuándo se publica la página. La combinación de clases de base de actividades no parece ser una buena combinación. El presentador Puede producirse en masa y no quiero definir un campo de presentador en acto cada vez, lo cual es extraño. Entonces esto es difícil. . . . .

Se ha estudiado durante mucho tiempo para reducir el grado de estandarización de mvp. Esto se puede considerar. Después de todo, el propósito del patrón de diseño es reducir el grado de acoplamiento, no como pretexto. No es necesario cumplir estrictamente con mvp. Puede reducir el grado de estandarización de mvp para acelerar el desarrollo. Pero la combinación perfecta de métodos de producción en fábrica no es muy buena.
En el entrelazamiento posterior, tengo tiempo para mirar algunos métodos de construcción de marcos externos. Finalmente, encontré una experiencia especial de mvp bajo el github de un león de asedio de los Estados Unidos. Entre ellos, él tiene algunas líneas de código para mí Descubra la habilidad para resolver el problema. Publico
mi código de muestra finalizado a continuación:

1. Aquí está MainActivity,

1. publicclassMainActvityextendsBaseCommActivity <MainPresenter> implementaIMainView
2. {
3. @ViewInject (R.id.lay_main)
4. Viewlay_main; // Un diseño en Android en sí no se usa para algunos cálculos, por lo que no es necesario solicitar el tipo como str_title en el nombre. Ya sea RelativeLayout o LinearLayout, generalmente solo se usa para hacer clic, por lo que todos los nombres comienzan con lay independientemente del tipo
5. @Anular
6. protectedClass <MainPresenter> getPsClass () {
7. returnMainPresenter.class;
8. }
9. @Override
10. protectedintgetLayoutId(){
11. returnR.layout.activity_main;
12. }
13. @Override
14. protectedvoidinitAllWidget(){
15. lay_main.setOnClickListener(this);
16. }
17. @Override
18. protectedvoidclickView(Viewv)
19. {
20. switch(v.getId()){
21. caseR.id.lay_main:
22. {
23. showMsg();
24. }break;
25. }
26. }
27.  
28. @Override
29. publicvoidshowMsg(){//测试
30. toast("isshowmsgmethon");
31. }
32. }

2.请看IMainView

1. publicinterfaceIMainViewextendsIBaseCommView{
2. //在原有IBaseView的初上加一个方法要求MainActivity必须重载这个方法
3. publicvoidshowMsg();
4. }

3.MainPresenter

1. publicclassMainPresenterextendsBaseCommPresenter{
2. //请求
3. privatestaticfinalintREQ_GETAPPLIST_MSG=0x002123;
4. privatestaticfinalintRES_GETAPPLIST_MSG=0x002124;
5. privatefinalStringSOFT_JP_FLAG="soft_jp_flag";
6. privatestaticfinalStringCURRENT_PAGE="current_page";
7. privatestaticfinalStringPAGE="page_size";
8. privatestaticfinalStringSOFT_TYPE="soft_type";
9. @Override
10. publicvoidhandMsg(Messagemsg){
11. switch(msg.what){
12. caseREQ_GETAPPLIST_MSG:{
13. MainRequestreq=newMainRequest();
14. req.put(SOFT_JP_FLAG,2+"");
15. req.put(SOFT_TYPE,1+"");
16. req.put("soft_jh_type",0+"");
17. Stringmac=WifiUtil.getMacAddress(iView.getActivity());
18. req.put(CURRENT_PAGE,1+"");
19. req.put(PAGE,10+"");
20. req.put("mac",mac);
21. req.setResPonseMsgWhat(RES_GETAPPLIST_MSG);
22. sendHttpPost(req,MainResponse.class);
23. iView.showProgressBar();
24. }
25. break;
26. caseRES_GETAPPLIST_MSG:
27. {
28. iView.hideProgressBar();
29. if(msg.objinstanceofMainResponse)
30. {
31. MainResponseres=(MainResponse)msg.obj;
32. if(res.isSuc()){
33. AppMainModelmainModel=res.getData();
34. iView.toast(mainModel.data.size()+"");
35. }
36. else{
37. iView.toast(res.getMsg());
38. }
39. }
40. }
41. break;
42. }
43. }
44. @Override
45. publicvoidinitData(BundlesaveInstnce){
46. getHandler().sendEmptyMessage(REQ_GETAPPLIST_MSG);
47. }
48. }

可以看代码 activity中没有MainPresenter这个字段，只是在getPsClass() 的时候返回的Presenter的类型，这个getPsClass() 的调用是在activity的基类里面写的，在基类中实例化了presenter，实例化之后，presenter会执行绑定IView，IView就是this了，基类的act在基类里的消息机制的处理方法直接传递到了presenter中执行了，所以，这样写Mainactivity写的代码就超级少了。管理都在基类里面了。这种写法真的好爽！哈哈哈！

presenter应该负责一些逻辑处理，这是毋庸置疑，但是 有些逻辑又需要activity的参与，这也会带来的问题事 有些逻辑是放在activity好还是presenter好，那么我们犹豫该放在哪里的时候，只需要根据一点判断，act是 view，frag是view，他应该只是负责一些控件，presenter是管理者，他就不要直接去管理view，这样子很多东西就想通了。

但是android比较特别的是act，frag都有自己的生命周期，这就是android特别的地方，跟做网站后台的区别就拉开了，具体生命周期内的一些操作，就要看你的个人喜好去分配了。

如果你也在研究mvp的更好的方式，更好的使结构更清晰，更加加快开发速度，那你看下我的代码，找下是否有你需要，来解决你的一些困惑，我也是才疏学浅，希望大家多多指点相互学习。 或许MVVM在数据绑定这块比mvp更适合，但是 mvp的自由行很大有些细节还是需要你自己的去推敲，别人说的再好也只是说个概念罢了。

代码地址： http://code.taobao.org/svn/frame_mvp/

代码挂到了 taocode上面， 用svn检出即可，我的github上不是这个框架，是我改版的另外一个老外的mvp框架。

PS：最后补充几句，其实设计模式你玩的再好也只是达到了解耦的目的，但是代码的可读性的问题还是需要你业余多多学习下好的写代码方式，不要明明都是 button1 button2 ，写switch case 1 case 2 case3 回头来看你的btn 看你的case 23456789 鬼知道你表达什么意思，你个SB。多去分析下哪些开源的框架，既能懂得原理，学到知识，还能学习到好的代码风格。 就像 你看我的代码没在view presenter中解析服务器返回的json一样，我都写在数据请求里面了，服务器本身返回的就应该做到很标准，做到你不需要判断全都可以转model ，转java bean，这才是好的服务器开发人员。 view 和 presenter应该做他应该做的事情，不应该去负责json解析的这种事情，我的swich case 也没用123456，而是用常量代替， 我不需要去为每一个case写注释，也可以清晰的看到这行代码就知道他表达什么意思，很多代码风格还是要去仔细推敲。 我不多说了。