※ 引述《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字串执行
这样的作法在维护或分工上，是不是比原本的方式简单了些？
最后，其实架构每个人实作的方式不一定相同，可以弄得很简单，也可以弄得很复杂，
单纯是以考量的因素来作选择，但前提是要在你观念正确下的考量来选择，
这样架构的实作才会符合你真正的需求。