WEB网站架构设计

damao
  • 423

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

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

回复
阅读 6.1k
9 个回答

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

屏幕或者内存太小?

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

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

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

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

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

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

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

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

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏