手机接口框架的选择

[wyang0126]

碰到个项目，服务器是用的jboss，项目主要是给手机端提供服务接口，项目是基于JSF框架的，手机接口主要是通过一个servlet来写的，所有的手机端请求，都是请求这个servlet，不同方法的请求，是用一个type来区分的，想问下这样的会带来什么问题？反正我是看着挺别扭的

[爱跳舞的铅笔头]

不会有什么问题，只是代码可读性不高。

[bobolnear]

不是框架问题，这是设计问题，如果业务种类繁多，一个type 区分得了？但是回过头来说，如果这个项目本身在设计上就考虑到业务种类不会太多，那么这样做并没有什么不可以，所有的设计 都是不断完善起来的，用大框架不见得 就好，主要考虑点还是在成本，后期维护，后期扩展上。

[tony4geek]

你从可读性，可维护性去看，，那种方便用哪个。

[wyang0126]

引用 2 楼 bobolnear 的回复:

不是框架问题，这是设计问题，如果业务种类繁多，一个type 区分得了？但是回过头来说，如果这个项目本身在设计上就考虑到业务种类不会太多，那么这样做并没有什么不可以，所有的设计 都是不断完善起来的，用大框架不见得 就好，主要考虑点还是在成本，后期维护，后期扩展上。

其实业务还是挺复杂的，维护和扩展上看，我很清楚，我想知道 还有没有其他比较深的影响，比如 性能、并发上什么之类的，项目负责人也不大愿意换，能挪就挪的感觉

[wyang0126]

引用 3 楼 rui888 的回复:

你从可读性，可维护性去看，，那种方便用哪个。

这些我都了解，我用着反正是不太爽，我想知道是不是还会有更深的影响，以后项目越来越庞大，对性能上，并发上等等 之类的

[bobolnear]

举个例子说，你要开发一个支持手机大学的高考录取查询服务，完美的方案当然是吧并发，分布式，缓存都考虑进去，但是这样的话，你的成本就相对高了，而且还需要专业的架构师。但是如果只是用现成的某一种框架，也许没有缓存机制，也没有分布式，更没有并发，但是它至少可以承受100个人访问吧，这样的开发成本最少，新手接手要求最低，如果遇到瓶颈，可以多部署几个应用，共用一个数据库，如果遇到并发导致数据安全问题，这时候在去找一个架构师 重构下后台的服务架构，还是可以接受的，虽然成本高，但是 当你有更多的需求来源就证明这个可以做，有前景，这点成本已经可以接受了