WEB网站架构设计

Question

目前 做的 web项目基本上都按模块划分，比如说用户模块，则会创建model ： user ，以及对应的 userDao ， userService ， userController
问题是我的userController 或者 userService中有十多个方法，感觉这样设计不是很科学，一个类中方法太多了点，有没有什么这方面的建议

不计较一个类有多少个方法算多，有没有这方面改进的建议，一个类太庞大怎么说都是很丑陋的

Answer 1

书看少了，多读书，多学习

http://www.infoq.com/cn/articles/implementation-road-of-domain-driven-design/

Answer 2

你这种是典型的事务脚本架构，适合于业务逻辑比较简单的情况。缺点是一个service承担了太多的职责，违背了单一职责设计原则。如果业务逻辑比较复杂，用领域模型架构模式好了。看看《企业应用架构模式》吧，大师之作。

Answer 3

屏幕或者内存太小？

Answer 4

一个controller中十几个方法总比你写十几个php文件强

Answer 5

需求越细，写的就越多。十多个，算不上多。

如果你实在觉得每个模块都这么写的话，觉得多。那么你可以把公有的抽出来，写个基类，然后去继承下，这样具体到每个模块可能会少很多，清爽些。不过增加耦合（自己看着干吧）

Answer 6

模块应该按照文件夹结构组织
举个栗子：仅仅是个例子，如果模块按照文件夹组织，就可以很方便，很干净
当然，发布产品还是要用工具进行构建压缩

-app
 |— controller
    |-client
    |-usr
 |— model
 |— store
 |— view
    |-client
    |-usr
 |—app.js
 |—index.html
-resources
 |— css
 |— images

Answer 7

不会重复使用的逻辑，可以让它的粒度稍微大一些。方法未必要拆分成那么多。

Answer 8

这个不能按照数量太看吧。。。。。。。。。。。。

Answer 9

有的时候有同感，一些类不是计划中的，是不断加进来的，即使不断重构，也不能阻挡甲方不断修改的需求。。。。。。。。希望找到好的解决办法