我最近在学习iOS编程。我打算编写一个简单的app，这个app的功能是：手机拍照，然后把照片传到用java+Tomcat写的服务器后端，后端负责对照片进行一些图片处理的操作，然后再把处理过的照片以及照片的一些文本EXIF信息（比如拍照时间，镜头参数等等）传回手机端。
我想请教一下大家，要满足上述的要求，后端应该采用一种什么样的设计模式比较好？ 我在网上搜了不少设计模式的内容，但感觉没有找到一个很相关的。希望能在这儿找到一些帮助。我现在采用的工程结构如下：
-
model: 包括所有的model类 -
controller: 包括所有和HTTP requests相关的类，用来进行网络相关操作，比如：接收、发送照片 -
service: 包括所有图片处理相关的服务类 -
dao: （Data Access Object）包括的类用来和数据库进行交互，比如：记录一些文本信息
请问大家：
- 我上面的设计对我当前想做的app合不合理？
- 感觉
service这个词太宽泛了。以后我还打算增加其它不同的服务，比如：物体检测、识别。这样的话，service里面就显得比较乱。图片处理和物体识别的服务完全可以看做两种完全不同的服务。我想请教一下各位，这种情况我应该怎么管理比较好？比如新建imgprocservice(Image Processing Service) 和imgrecservice(Image Recognition Service)？但感觉名字就太长了一点。 - 如果各位知道什么好的手机app设计前端和后端相关的设计模式的入门资料的话，还请推荐一下。
谢谢大家。
这大概就是一个标准mvc后台框架的结构, 稍微举个例子并且纠个错:
-
service理解成一组与业务相关的服务, 比如洗衣店提供洗衣服的service,那么我用这个service就能得到洗衣服这个业务. - 不知道你这里的
dao和model有区别吗, 都是对象化数据库操作,拿洗衣店的例子来说的话, 就是洗衣机,洗衣机上的一排按钮就是model的方法, 谁来按这些按钮,就是service了, 干洗service按的一组按钮肯定跟水洗service就不一样了. -
controller理解为洗衣店前台就行了,你掏钱说我要干洗, 那么前台会给你调用干洗service, 你如果说还要烘干,那么controller就会调用干洗和烘干两个service -
imgrecservice的名字太短了，命名不要缩写，你确定你过两年还知道这缩写是什么意思吗，叫imageRecognitionService都不长,而且一眼就知道是啥 - 设计模式是用来解决特定问题的, 叫叫英文pattern的话更好理解一些, 就是类似的问题出多了,解决这类问题的方式都差不多,就可以归纳总结出来一个pattern, 再碰到问题往上套就可以了,因此是先由问题,再考虑用pattern解决问题. 这里你的大问题是后台应用,各种框架都是用MVC来解决这个问题,所以也很自然就能想到用这种pattern.
- 另外纠正一下FP/OO是编程范式,只是描述你写代码的方式,解决的问题也不同,FP更方便处理数据,组合函数,没有副作用和状态可并行,而OO则是行为和状态变化的抽象.因此解决的问题也不同,通常复杂问题需要多重范式来解决,这也是为什么很多语言都是支持多重范式的,如ruby, scala, 现在连java都支持lambda...
没有好模式，只有合适的模式。只有实际去写代码，去改代码才能知道模式的好坏。我觉得最不合理的就是代码还没写出来就来研究设计模式，希望“先学好设计模式，然后一下子写出很好的代码出来”
抄一段我以前的回答过来
写代码的时候我不会刻意地想：啊今天我要用FP/OOP/XX原则。
好代码是经历时间改出来的，好思想是对着好代码总结出来的，这个顺序我觉得不能反，刻意地想着某某思想去写代码很容易进入误区
最后，如果你既不会写iOS，又不会写后端，然后以后的方向又希望以iOS为主，那么强烈不建议你用Java来写后端，这会牵涉你很多不必要的精力。推荐python / ruby / nodejs 这三个平台，都是学习成本不高，类库丰富，轻便灵活的平台，我个人认为更适合iOS程序员写简单后台