问一下有关三层结构的问题。

[ghosthjt]

看了这个版块，发现很多地方都在说软件的三层结构的问题,(表示层,业务层,数据操作层)
我想问一下具体来说怎么来建这三层结构的类，各位达人说说思路是怎么样的。因为我从来没有用过这样的模式.比如说开发一个人力资源管理系统，这三层结构大致应该怎么建呢?

[zengjd]

最早的程序是不分层的,比如早期的批处理系统,只要编写操作某些文件格式的程序.
后来,随着客户机/服务器系统的出现,分层的概念就明显了,这样的系统是两层结构,客户端包含界面也包含应用代码.服务器端是数据库.但领域逻辑复杂并且易变时,这样做会有很多缺点,冗余代码,不利于重用,不利于分工等等.
再后来,面向对象的编程序的思想普及了,面向对象为领域逻辑问题找到了答案,转到三层架构的系统,在这中种方式下,表现层实现用户界面,中间层实现业务逻辑,在数据源层存取数据,这种方式可以将复杂的领域逻辑从界面中抽离出来，用对象加以建模和组织。
注意：三层结构不是物理的分层，客户机/服务器是两层的结构，它是物理的分层，客户机在一台台式机器上，服务器端是一台服务器，而三层机构无需把不同层次放到不同的计算机上运行，独立出来的领域逻辑层无需放到独立的计算机上，如果数据库在本地，也可以在一台机器上运行三层系统。
具体如何分离取决于系统的复杂度，从数据库中读取数据并将其在界面上显示，可能在一个过程中完成，但仍然存在三个层次，可能在这里只是把三个层的行为放到三个子程序中。如果系统稍微复杂一些，就可以把三层做成三个类，依此类推。但至少切记一定要进行某种形式的分离，至少在致程序级。
领域逻辑可以进一步分层，形成多层结构。

[lisir010]

不错

[oyljerry]

3层机构一般是逻辑上的
表示层，就是你的系统界面等
业务层，就是界面中的输入数据或别的信息
数据操作层，就是数据的查询，结果的返回等

[hedonister]

所谓的三层结构设计

1.ui层，也就是界面层，用户交互包括你说的后台，因为管理网站时你其实也是个用户，所以不分什么给人浏览的部分就没必要用三层，一样要用；具体是这样的你把关系到业务处理的程序剥离出来，在ui层只处理一些界面上必须的东西，比如绑定个数据，datagrid显示效果啊，按扭等控件的显示风格什么的；

2.业务逻辑层，就是具体处理你的业务了，比如根据ui层传来的条件组成sql语句，对具体某个业务块对得到的数据进行业务处理，千万记住在ui层最好不要出现完整的sql等暴露数据库结构的语句，因为关系到安全的问题，到这了，就可以谈数据处理层了；

3.数据处理层，完全是用来处理与后台交互的操作，应该是跟任何业务都没有关联的，这里应该是重用率最高的地方，如果开发过几个系统就应该可以形成一个比较成熟的数据访问层了，可移植性很强通用性很高，建议看看微软的accb，这块是干什么的清楚了，再补充句，通俗点说就是将你在业务逻辑层组好的sql语句交到ado.net或后台执行，你得到结果或对后台数据库数据进行更新等操作；

[ghosthjt]

程序本来就是要这么写的嘛，肯定要有界面，肯定要对数据库进行访问,这样不叫分层吧??
我现在的做法是，一个类里包含了对数据库的操作，也包含了业务的逻辑，但不包含用户界面。

[zengjd]

既然你明白了就赶快结贴

[ghosthjt]

难道这些就是传说中的三层结构吗??

[将就点]

软件体系结构还要自己多多联系才能体会深刻，试试写写简单的MIS，怎样安排你的软件结构才能做到

1：条理清晰。团队（3人以上）能够很容易理清你搭建的体系脉络
2：维护量小。如何作才能使小小的必要的改动对整体改动要求最小
3：升级方便。当客户端界面需要变化发展，但是业务功能不变，或者业务功能改变，界面不需要改变，或者二者相应发生变化，或者数据库或者数据表的改动时，怎样做最省事。
当这些你做到的时候，你就明白 hedonister(冰戈) 说的是什么了。^_^

[将就点]

有时间看看C＋＋之父写的C＋＋程序设计语言，里面对软件组织，分层结构有过深刻的论述

[XACZ]

学习

[lemong]

简单说来

1.ui层，也就是界面层.
在ui层只处理一些用户输入(包括输入检查),输出,中间的数据处理都交给业务层(也就是相关的业务类)处理.比如,人力管理,这里就是web portal的页面.

2.业务逻辑层，就是具体处理你的业务了.
这里只是用户输入的数据做简单处理后传给数据层(数据访问类),或者把数据层返回的数据做处理后返回给ui层.比如,人力管理,员工管理类(包括员工属性,员工的新进,员工的调动,员工的离职)

3.数据处理层，完全是用来处理与后台交互的操作，应该是跟任何业务都没有关联的,只和数据库有关系.这里的没个类说白了,就是针对每个表做处理的(增加,修改,删除)

[I_Iverson]

为了体现oo的优势，为了组件的重用，为了web层代码的清晰。

其实分层就跟你在一个类里面写方法的道理一样，如果一个方法太大，包含了太多的逻辑，肯定会让人摸不清头脑，所以，你就有可能把这个函数重构，会把这个大方法分成几个小方法，一来你的代码清晰了，自己和别人好看，二来重构出来的方法有可能给别的地方调用。多层也是同样的道理。。。

有时你觉得一个大方法分成两个小方法还不够，还想分成更多的方法更方便。 分层也一样，如果三层不够了，你再分多层就可以了，直到够用。

[I_Iverson]

还有个说法是便于分工，个人不怎么赞同

[qrlvls]

还在讨论三层结构是否有些过时了？

[xyj0323]

楼上的何处此言！