Re: [问题] 请问一个MVC的实际案例

楼主: alanturing (alan)   2016-04-08 04:05:22
※ 引述《q374077 (q374077)》之铭言:
: 越google越怀疑自己到底有没有懂
: 架构是android->php->mysql
: 我在android端写几个controller
: (就是各种SQL,select A、select B WHERE x = y 之类的)
: 写一个php在local server做model接收和发送资料给controller
: view的工作就是把controller丢回来的结果用json解析,表格或条列,显示给使用者
: 好处是资料安全和可以各自分开编写,对大型专案有利
: 坏处是比较复杂
: 请问我这样对mvc的架构算是了解了吗?
半夜睡不到,看完这篇文章之后有点心得
首先,我只是个刚出社会几年的小小工程师,所以有些我说的观念未必是完全正确,
以下内容你可以当作参考就好。
每种架构都是为了一些目的而设计出来使用的,而对我来说,
我使用MVC架构有3种目的:
1.将复杂的程式简化,使程式能更直觉易读。
2.使程式架构变得更容易扩充及重复使用。
3.分工合作,架构独立后可以更仔细的分工。
很多语言都有MVC架构,而Android其实本身就是一个MVC架构的专案,
Model - source里定义的字串、阵列等...
View - 画面的xml档案
Controller - activity, intent
若不考虑网络环境、程式复杂度的话,其实就是一个简单的MVC架构了,
当然如果把其他因素也放进来的话,这个MVC架构彼此之间就会变得模糊,
所以网络上就会有许多大神做出分工更仔细的程式架构,
至于要使用那一种程式架构来开发,纯粹是个人的喜好,
开发久了自然就会慢慢写出符合自己习惯的程式架构。
你提到的资安问题跟MVC架构其实没有什么太大的关系,
分开编写是MVC架构的目的没错,只是你可能没有用对地方,
以你提到的SQL写在Controller里的作法,对MVC架构来说,并不能说是完全不对,
因为对小型专案来说,写在Model或Controller来说,并没有太大的差别,
只是你必须考虑的是现实的工作环境,
以MVC架构来说就是区分成美工、程式开发、DBA三个工作,
如果不是屎缺的话,这些工作可能是由三个人以上来分工负责,
如果你把商业逻辑写在Controller,SQL也写在Controller,
那程式开发跟DBA的工作就都混在一起,是不是开发上也会更不容易分工?
另外一个问题是,如果你今天有Android、IOS、桌面系统三个平台,
那如果要修改SQL语法,不是三个平台的程式都要改一次吗?
而且还要注意每个平台之间的SQL语法是不是都有写对,
这样的作法是不是让程式变得更难维护了?
所以我有另外一种想法,你可以参考看看,
1.先在Controller里处理完你要存的资料
2.将资料传到Model
3.Model再将资料组成SQL字串执行
这样的作法在维护或分工上,是不是比原本的方式简单了些?
最后,其实架构每个人实作的方式不一定相同,可以弄得很简单,也可以弄得很复杂,
单纯是以考量的因素来作选择,但前提是要在你观念正确下的考量来选择,
这样架构的实作才会符合你真正的需求。
作者: q374077 (q374077)   2016-04-08 16:54:00
感谢a大,分工确实是辨别的好方法,原来因为android架构下已经是mvc,应该是我自己串的远端DB的部分还不完全成功所以才觉得我好像是又好像不是...
作者: aw038 (GuanY)   2016-04-08 18:31:00

Links booklink

Contact Us: admin [ a t ] ucptt.com