那东西主要就是将应用逻辑(业务、商业逻辑)抽象出来,与前端表现界面分开,从而体现三层、多层结构的易拓展、易维护性的特性。

业务逻辑又分为业务规则和业务外观

分开设计的目的是提高应用程序的可伸缩性和可维护性。如果你的应用程序在运行一段时间后,需要修改某些业务规则,你不需要对其它部分做大量的改动,如果你的程序结构做的很好的话,甚至可以不需要对其它部分进行变动。

.Net技术的架构应用

对数据合法性的校验放在前台,而对数据的计算等处理放在后台  
  不可能把所有逻辑全部放在后台,这样看起来逻辑清晰了,但是效率太低了。

三层结构的项目做了好几个,有大的有小的。  
      有些感触,很想说出来大家分享分享:  
      1.软件架构和设计的问题.  
          很多时候我们的设计还停留在最初级阶段,从设计TABLE然后划分模块,定一些粗浅的规则,然后就是各个程序员拿著各自的模块,各显神通了。这样设计出来的东西,不管是采用三层还是两层,其结果都是模块化的,哪怕采用三层架构,其实就是把两层中的一大堆逻辑堆在应用服务器端,做出来的程序就象李维所讲的,large   business   object,根本不能很好的复用。  
      2.效率问题.  
          我觉得这不太是个很大问题,尤其是涉及到数据库连接的时候。其实一个企业内部用的系统,一般有二十个user同时在线就算是比较大的系统了,这种二三十个user同时在线,三层结构未必比两层结构效率高。  
          如果是要追求效率,可以有很多种方法,如大量的数据移转采用存储过程,大批的数据下载分批的方式等等,这些措施可能比单纯的优化数据库连接要有效。  
      3.软件技术的限制.  
          COM架构,我觉得它有一定的不足(不然微软就不会采用.Net),如组件(或者COM对象)的继承就很不好或者说不能处理。这样大家如果要在服务器端建个好用的Application   Framework几乎就成了Mission   Impossible.  
      4.业务分工的问题  
          国内的软件开发方式基本都采用每几个程序员负责一个模块的方式,一个程序员写了business   logic,写了data   access,还要写UI,这样的分工导致每个人只关心自己的那一个模块,对于和其它模块的交互基本就不闻不问了(要问也问不到)。  
      我个人觉得,如果开展项目,如果没有一个很好的前期基于OO的分析和设计,  
  不管是三层还是两层,都会有问题。甚至三层问题更大。如果OOAD的工作作扎实,  
  再辅以三层这种分布式的软件架构,才能真正做到说复用性高,效率高的系统。

所谓的业务逻辑和界面的分离,并不是在cs不需要,在bs或多层就需要。  
  其实这是社会分工越来越细的要求,也是面向对象的开发的要求。  
  拿企业级应用系统来说,每个企业的需求都是不同的,对于界面的需求也不同。  
  在别人的指导下能调整调整界面的程序员,随时能找到。而能编好业务逻辑的程序员真的非常难找。因此你要让高水平的程序员去把注意力集中在业务逻辑上,不不用花时间去调整界面。  
  我们做的是cs结构的,我们的做法是在所有的form里都不直接使用dataset,而是在相关的datamodule中放dataset,   并且建立专门的业务处理类,其中包括dataset,   form中只是调用datamodule和业务类中的函数。而不会把界面操作和业务处理混杂在一起。我们基本消灭了100行以上的函数。每个函数都短小清晰明确。

1,客户端:基本的数据浏览,数据验证;(强调一个瘦字),所以数据传输最少化,这种最少化应该通过中间层的控制来达到。  
  2,中间层:企业逻辑层,复杂的算法和逻辑规则;(强调一个全字),所有客户端的要求都由中间层来控制,包括到数据库取数据(取多少,取哪些),因为要满足很多客户端,所以这些要求不是和客户端一样的。  
  3,数据层:保证提供中间层所有的数据和保证对数据的各种操作能够顺利进行。  
   
  分层的目的是为了实现分布式,控制整个系统的平衡负载,故障负载,实现系统的柔性。  
  一般来说,中间层建立完整的企业com+逻辑组件对象,完成客户端需要的全部服务,中间层对数据的操作一般来说不使用针对某些数据库的存储过程和其他一些东西,因为要实现对不同数据库系统的控制。使用中间层组件能够更好的实现代码的重用,如果我们应用面向对象的方法考虑时,客户端:发出指令和要求,同时得到反馈,中间层:正确完成指令要求,并反馈,数据层:提供指令所需要的数据,存储返回来的数据。  
  在考虑两层的时候,我们考虑的服务端不多,很多人心中只是一个,其实服务端也很多,有时候客户端和服务端交杂,如果你提供服务,你就属于中间层,如果仅仅是发出指令,就是客户端。

这不是绝对的,业务逻辑只是尽量的放在中间层,请注意,这么做的理由  
  1、可以尽量少的影响客户端  
  2、减少传输数据量  
  3、增强系统的安全性和健壮性  
  实际上,这些理由才是主要的,我们考虑这些理由,  
  1、尽量少的影响客户端,如果业务逻辑发生比较大的变化,那么还是要影响客户端,这说明客户端和中间层的耦合仍然是很强烈的,但是也有极端的例子,B/S结构的可以说完全不会影响客户端,因为那是IE作为客户端,但是问题是灵活性太高,不得不输出客户端脚本控制IE的行为。  
  2、减少数据流量,如果客户端的非法数据过多,都要传输到服务器验证,那么废数据的传输量仍然是可观的。  
  3、安全性和健壮性,基本没有影响。  
  我的建议:  
  业务逻辑在中间层和客户端的分布应该是折衷的,不是绝对的完全放在中间层。有以下的原则可以参考  
  1、敏感的数据验证活动,比如用户的密码、权限等等必须放在中间层。  
  2、可以减少减少网络数据传输开销的逻辑放在客户端,比如根据根据某些原则获得数据或者修改数据,那么就不必把所有的数据都传输到客户端。一部分的数据合法性检查也要放在客户端,避免非法数据传输。  
  3、需要其它数据组合才能进行的合法性检查放在中间层。  
  4、可以减少服务器负载的业务逻辑放在客户端,这也是折衷的,如果服务器比较好的话,就可以多放一些在中间层  
  5、客户端和中间层的逻辑交叉要尽量少和单纯,这基本上要求严格的,甚至牺牲性能来满足这种要求。  
  6、客户端要尽量的具有扩充性,如果客户很多的话,可以牺牲性能,极端的情况,使用B/S结构,B/S结构可以把客户端的逻辑跟随客户端脚本一起下载,使用这种模式需要认真地考虑安全性。

对大量的数据的表,是不能一次取出,就算按照clientdaset分批取的话,在应用服务器上,也会缓存一个大的数据集,同样影响效率。  
  所以应该由客户段发送sql语句。取少量数据,同时服务器不维持这个状态。如客户段需维护。根据控件及摸班很容易动态拼出sql语句到应用服务器执行

我觉得我们在讨论B/S和C/S,或者两层和三层时,应该理解他们的特点和主要解决的问题。  
  我觉得把界面和业务逻辑分离最大的好处是可重用,这一点不一定是在一个项目中体现,而且在一系列开发的项目中都可以重用或只修改业务逻辑。业务逻辑的设计我觉得要结合OOP的思想,把一堆C/S程序中的业务逻辑处理函数什么的搬到应用服务器中,我觉得没有体现三层的真正含义。  
  三层架构的提出,我觉得主要是为了大型的,用户数目很大的,业务特别负责甚至经常修改的项目,所以有负载均衡、客户易维护等特点。但我们国内更多的项目并不具备这些特点,所以会觉得标准的三层构架很理论,我觉得我们应该根据系统的特点来选择的两层或三层的技术。  
  象连接池这些技术,实际上是牺牲速度保证用户数,如果我们项目本身用户数不多,我觉得就可以保持数据库连接打开,以保障速度。  
  再象返回数据集也一样。一味减少返回数据集的记录数肯定会加大用户的操作时间,不管是让其输入检索条件还是通过翻页。(当然有些技术并没有这么大的副作用)  
  总之,我觉得三层架构有其先进性,关键看我们如何结合具体项目来取舍其中的技术。就象围棋,所有定式基本上都是利益均衡的,但结合具体的一盘棋就有不同的选择。我们就象那些下棋的人,还   没有水平发明定式,只能研究一下各有什么特点,该怎么用?  
  发表自己的拙见,如果不对,请别...哎呀,谁踢我:)

应用逻辑(业务、商业逻辑)抽象出来相关推荐

  1. 商业逻辑12讲之人力资源的逻辑

    目录 1. 概述 2. 核心课第一讲:人力资源的基本逻辑 3. 核心课第二讲:人性假设的逻辑 4. 核心课第三讲:人力资源管理的基本目标 5. 核心课第四讲:组织用人模型的逻辑 6. 核心课第五讲:招 ...

  2. 区块链通证经济的核心不在技术,而在于商业逻辑的重构

    近两年,区块链迅速在国内掀起一股火热的风潮,随即成为第一个风口.这也吸引了大量的人走进这个行业,很多人对区块链的看法,也是相当看好的. 甚至有人评价:"区块链是世界第九大奇迹",目 ...

  3. 从商业模式到商业逻辑,美团的“难处”究竟在哪里?

    文 | 无兮 来源 | 智能相对论(ID:aixdlun) 外卖平台们的舆论环境颇有点"冰火两重天"的意思. 一边,是饿了么通过各种积极投入帮助商家度过难关,在营造良好的品牌形象, ...

  4. 打车软件烧钱背后的商业逻辑

    这两个月快滴又掀起了打车应用的烧钱狂潮,消费者切实得到了实惠,而不少有意识的司机,也都纷纷当起了出租车司机,甚至传言有不少的人都月入过2万,这让多年的程序员情何以堪啊!在跟一个产品经理的朋友进行深入交 ...

  5. 商业逻辑12讲之技术创新的逻辑

    目录 1. 概述 2. 创新的重要性 3. 创新的基本概念 4. 创新的管理模块 5. 技术创新的战略管理 6. 技术创新的组织设计 7. 培养创新人才 8. 技术创新的文化建设 9. 小结 1. 概 ...

  6. 商业逻辑认知:华为为何不倒?微软为何重生?瑞幸能干掉星巴克吗?

    文/技术领导力社区 编辑/Emma 华为为何崛起,为何屹立不倒?微软错过互联网时代.移动时代,为何又获得重生?瑞幸的对手是星巴克吗,战争何时打响?IBM为何砍掉PC业务? 任何一个商业组织都有它成长的 ...

  7. ”半越狱“的商业逻辑

    "生态系统"是一个非常吸引人的商业词语,IBM依靠"生态系统"实现了大象跳舞,微软依靠"生态系统"统一了PC世界,而苹果更是依靠" ...

  8. 你的产品是否符合基本的商业逻辑?

    你是否踌躇满志思考该如何构建新业务并创造价值?抑或是雄心勃勃思考如何改善.变革你的产品?借助商业模式画布可以辅助你一步步探索产品背后的逻辑. 2008年,著名商业模式创新作家.商业顾问亚历山大•奥斯特 ...

  9. 「得屌丝者得天下」背后的商业逻辑

    上一次「屌丝」这个词走进我心里,还是那年带我妈在欧洲玩的时候. 我们在罗马下了火车,我拉着行李箱,穿着心中最潮的oversize的工装外套和最显瘦的boy friend风的牛仔裤走在前面,我妈从后面追 ...

最新文章

  1. 信息理论基础 周炯槃 常迥
  2. 90后清华女孩:博二开始研究世界级难题,3年发5篇Science,现入选中国榜“35岁以下科技创新35人”!...
  3. ICLR 2021 | 显存不够?不妨抛弃端到端训练
  4. c调用按钮点击事件_Unity3d---对UI事件接口的一些测试和机制(坑)的总结
  5. tomcat的备份脚本
  6. 超有用的方法-----英语单词记忆篇
  7. python四大高阶函数_四大高阶函数
  8. Win11玩永劫无间闪退怎么办?Win11玩永劫无间闪退的解决方法
  9. VC++的Unicode编程(经典之作,交流传薪)
  10. 为什么国外程序员加班少?他们这样评价996和技术公众号
  11. 有关Unity编辑器
  12. Delphi 7 在Win 7 下的安装使用
  13. Github - 第一篇:Github安装与配置
  14. Kafka实战之整合Flume和Kafka完成实时数据采集
  15. Java在一定范围随机生成经纬度
  16. [中文/英文]VC6 sp6补丁下载|VS6 sp6补丁下载 [防VC6link死机]
  17. 头文件注释轻松搞—VS2013
  18. 有源晶振和无源晶振区别
  19. 全景拍摄—焦距与对焦教程
  20. OpenCV之图像ROI与ROI操作

热门文章

  1. 云计算(三):工业互联网概述
  2. Python之Selenium的基本使用(1)
  3. 论文修改建议 (HuangP 20211102 算法描述)
  4. library的英语怎么读音_library的英语怎么读音_这样学英语,方法老土,却很有效...
  5. 番茄助手无法安装的问题
  6. Python 学习笔记 第三篇 Python实现网易云评论网页爬虫+词云展示 (Pycharm+Mysql)
  7. cadence 的常用快捷键
  8. 基于python的时间序列案例-时间序列预测全攻略(附带Python代码)
  9. bullmind在线uml软件
  10. linux aws mysql5.7安装