Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

模块定义与目录结构的矛盾

  类的封装是一种从底层到顶层的过程,底层类实现一些基本功能以便复用,顶层类则是实现具体的业务逻辑的。而模块生态系统则完全相反,从业务顶层的业务逻辑入口,选择性地引入其它子模块,最终才会依赖到底层模块。说着说白了就是模块的定义和使用顺序问题。
  昨天我就在纠结模块的使用问题。如果模块的入口是从业务层开始去引用底层,那么各种层级的依赖就会冗余。除非层级的纵深去掉,做成扁平依赖的,否则无法解决这个问题。所以,更科学的目录设计应该是模块定义时的设计方式,也就是像类继承那样的层级关系。
  「底层」和「顶层」的概念其实很奇怪,就像说香蕉哪边是「头」一样很难说清。在我的定义中,「底层」和目录结构没关系,通用组件、基类,这样的东西属于底层,业务层属于顶层。
  在组织目录结构时,把底层模块放在树根的方向上就可以避免冗余。但是在做业务开发时,我们是从业务模块也就是从顶层入手的,如果顶层不在树根方向,寻找入口就会很麻烦(项目开发时通常是从树根方向入手,一级级把目录点开的)。
  上面这对矛盾就是目录结构设计的纠结点。好像也没有什么完美的解决方案,也许层叠依赖根本不是一个好主意。
  我经常喷 CSS 所有东西都是全局定义的,现在想想确实也有点感触了。UI 组件这方面的东西全局定义才更易用。虽然业务复杂时会很乱,但确实解决了一些逻辑上的矛盾。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^