应用逻辑（业务、商业逻辑）抽象出来

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

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

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

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