当前位置:和仁网 >其它 > 正文

编程规范 嵌套层数

2021-08-06 0

应该不会有具体的规定吧。嵌套越多的程序越难遇到,不过针对具体的问题,应该不要受具体的限制,否则就是教条。当开发人员在以前的两层结构中痛苦煎熬了很长一段时间,突然看到了三层结构的解决方案的时候,一般会有终于找到了救世主的感觉。但是这种感觉往往会导致掉到另外一个同样恐怖的陷阱“过度设计”中。在我以前曾经供职的一家公司,以前都是把SQL语句直接写在ASPX页面的,后来在读到了一些关于多层结构方面的资料之后,一下子又把整个系统分成了:表现层(ASPX)、接口外观层(IF),业务外观层(BF),数据访问外观层(DAF),数据访问层(DA)和数据访问组件(SQLHelper)。但是我并没有吸取教训,导致后来也犯了同样的错误。犯错误的原因有很多,不过主要是因为没有一个比较明确的如何分层的指导性原则。假如说我们分层的原则是为了抽象逻辑,分三层的原因是要让业务逻辑和界面及数据库解除耦合,那么如果按照这个分层原则,我把逻辑重新归类更加细的分为四层、五层、六层行不行呢?如果不行,那是什么原因不行呢?在没有正确的原则指导下,分层技巧很容易被滥用,导致分出许多没有必要的层出来。无端的增加了开发和维护成本,以及更重要的是增加了重构的代价,降低了团队的敏捷能力。面向对象架构设计大师Martin Fowler在介绍如何设计分布式系统的时候曾说过:分布式系统的设计原则的第一条是,不要使用分布式。他的意思当然不是说要绝对禁止使用分布式设计,而是劝导人们尽量把问题简单化。能不分布式设计的,就不要分布式设计。我套用他的这句话提出我对分层的感受就是:多层结构系统的设计原则第一条是,不要使用多层结构。当然我的意思也并不是说层数越少就越好,而是希望你能清醒的认识到增加层数会增加结构的复杂性,不要轻易的作出分层的决定,一定要到感觉必须要增加一层才能解决问题的时候,再来决定增加一层。过多的层次除了会给系统带来不必要的复杂性外,还会影响你的系统结构设计。如果你打算采用面向对象的领域模型来设计系统的话,在业务系统内的分层会给面向对象系统的设计带来很多麻烦,会很容易走回到事务脚本的老路上去。请看结构图



总结一下:1,建立一个完全面向对象建模的领域模型层,让这个层尽量处理多的业务逻辑。其它层尽可能的薄一点,把业务逻辑都转移到领域模型层中。2,UI尽可能和领域模型贴近一点,中间不要经过太多中转,物理边界也尽可能的少。3,业务对象只能有一套,也就是领域模型。只要出了领域模型层,外面全部是零散数据,没有对象的概念。4只有在领域模型层才可以处理对象。如果一定要分布式。全部用简单数据类型通过接口访问领域模型。 这个分层结构其实是经历了多次精简完成的,所有的感触都归结为一句话:不要过度设计,简单就是美。补充:请看清楚上面的解释,如果程序允许的话100层也可以掉用.由于编程语言的不同,可以调用的层数不同.比如:Visual FoxPro主要技术性能 1.程序文件与过程文件技术性能· 源程序文件中程序行的最大数 系统没有限制受可用内存的限制· 编译后程序的最大容量 为64KB· 过程文件中包含过程的最大数 系统没有限制受可用内存的限制· DO调用的嵌套层数的最大值 为128层· READ嵌套层次的最大层数 为5层· 结构化程序设计命令嵌套的最大层数 为384层· 函数调用时传递的参数个数最多 为27个· 事务处理的最大数 为5件没有依据或原则能明确规定或建议:"嵌套应该小于5层".没有这样的规定.
本周热门
本月热门