青岛正规网站建设哪家好,做网站编辑工作好不好,wordpress個人網站域名,龙岩互联网可以用这样的思想#xff1a; 最初的应用是单机#xff0c;数据和功能都放在一台机器上。随着应用向工作组模式发展中#xff0c;人们迫切需要 调用彼此的数据#xff0c;也调用彼此的功能#xff0c;这样人们就不用重复录入数据#xff0c;程序员也不须重复写 功能。数据…可以用这样的思想 最初的应用是单机数据和功能都放在一台机器上。随着应用向工作组模式发展中人们迫切需要 调用彼此的数据也调用彼此的功能这样人们就不用重复录入数据程序员也不须重复写 功能。数据和功能先共享哪一部分虽然说通过功能就可以把数取出来数据在功能屏蔽之下似乎 无须共享出来但是功能是基于数据的功能共享出来了单独放在一台机器上让大家使用但是这个功能 需要的数据在ABCD...上分布着到底是谁所以必须先共享数据。所以才有了C/S模式 一边是数据库大家都对着这台机器访问数据一边是大量的客户端程序都在每台机器上。 随着部门间计算模式的发展一个系统想存取另一个系统的数据但是表结构已经很复杂了 业务逻辑也已经错综复杂了你已经不可能独自写一段程序存取另一个系统的数据。这时只能合作 让对方写一个功能给你开放出来你一调用就能得到你想要的结果。但是这个功能写好是该放到哪台机器上吗 肯定不可能放在每个客户端上又需要单独放在一个机器上于是C/S/S产生了 这是一个历史你就明白了三层该放什么东西。 当然也顺便就是另一些系统不调用的功能也放在了这个公共组件服务器上来减少数据库连接 虽然有的文章上说这样可以减少更换程序的成本这点倒不敢苟同因为从实际开发中如果客户端是GUI的 你的很多改动会和GUI改变有关你还得更新。如果你客户端是WEB你还必须是三层因为你客户端什么都没有 至于划分数据层业务逻辑层只是为了引导你面向对象思考。说是为了更容易的修改而不影响另一层这个也是 比较困难因为往往客户要求多显示一些东西或少显示一些东西可以这样查可以那样查所以 往往数据层的SQL语句老变化而且大多不能在原SQL上改因为参数字段或许都不一样你改了客户段的取数就很容易出错 你也不敢保证它会在什么功能中被公用到所以往往是又增加一个新SQL和原SQL看起来90%一样但又不完全一样。 客户端界面也老变有时业务校验规则也不一样业务处理方式也不一样所以每层都需要改变 往往一个数据对象由两三张关系数据表组成 在数据层表现为数据对象但是由于业务处理的重点不一样也为了速度考虑取最必要的字段 所以在这个数据对象中有各种各样的SQL而不是一个SQL但是每个SQL都是反映了这个数据对象的一个方面 然后写一些函数专门针对这些数据对象做业务处理还有一些函数专门负责数据校验如不可为空主键重复类型出错等 在业务逻辑层分出两枝一枝是业务逻辑规则校验在其中也调用着数据层的数据校验规则 另一枝是业务处理就是调用数据层的各个函数来组合完成一件事形成一个流程 总结一下SQL一般都写在数据层这是很自然的业务逻辑层就是组合功能。不管数据层的函数 还是业务逻辑层的数据都和业务相关对于数据层与业务无关的说法在实际中行不通因为在模型上 说我们写在数据层上的那些接口方法应该是单独又分出一层叫真正的业务逻辑层而我这里写的业务 逻辑层模型中叫Facade就是为了简化客户端调用而做的外壳。但个人认为模型中单分出一层意义不大 因为每层都需要修改少一层就好修改一些。而且纯粹的面向对象系统在世界上也从来没有存在过如果 存在那必定是一个理论家的东西而不能实用就象在实际中我们在设计关系型数据库时先三范式后为了简化 编程和提供速度而反三范式。 客户端也不是多个功能放一个PAS文件中。因为客户往往要求功能组合。如A要和B功能放在一个界面 B和C要拆开所以客户端也是界面和数据操作和数据显示分开为了在界面上看到的是多个功能在一起 但实际中却各不混杂这是个功能模块划分不是层次划分。如果从界面观点来看是层次问题因为界面和功能算两个层次 不要拘泥于理论也不要放弃理论埋头编程而是互相借鉴前进目的就是两个为了业务处理需要 为了我们好维护程序。 再看看我开头讲的历史你会发现历史就是为了这两个目的而变化 转载于:https://www.cnblogs.com/coollzh/archive/2004/04/03/5067.html
