C/S模式开发

shuaifujian 2009-01-10 12:42:47

靠发现这边高手还真多我现在搞的是C++模拟开发数据库除了在学校里面学的到工作中几乎没用到对于C/s模式开发我在网上看到有两层模式和三层模式对于这两种模式网上没有说的清楚，我的理解是两层模式就是前端的应用层对数据库直接操作，而三层模式则加了个逻辑处理。我现在打算这样做把所有的数据处理放在类里面作为中间数据处理的一层不知哪位高人能说的清楚点。
注:这个加分怎么加啊看到你们回贴我想给你们加分不知道如何加：）

...全文

451 15 打赏收藏转发到动态举报

写回复

用AI写文章

15 条回复

切换为时间正序

请发表友善的回复…

发表回复

hello123_ccp 2011-06-20

打赏
举报

三层机构

fanyuanwaifdl 2009-01-13

打赏
举报

[Quote=引用 10 楼 dawugui 的回复:]
SQL code简单的说就是:
三层开发: DAO--data accessing object,
数据访问层 Service--
服务层,业务逻辑 UI----
显示层,可以是window(c/s)方式,也可以是web方式
[/Quote]·

gjz_1209 2009-01-12

打赏
举报

看具体情况吧，一般两层就够用了。

faith10099 2009-01-12

打赏
举报

现在用B/S更合适

weichaozu131083 2009-01-12

打赏
举报

太多的层维护起来非常麻烦，层与层之间的交互也是非常麻烦的，
现在的开发方式，业务逻辑大部分放到存储过程里，外面其实只要一个表示层和数据层就KO了，

dawugui 2009-01-12

打赏
举报

简单的说就是:

三层开发:  DAO--data   accessing   object,

数据访问层  Service--   

服务层,业务逻辑  UI----   

显示层,可以是window(c/s)方式,也可以是web方式

dawugui 2009-01-12

打赏
举报

所谓层,即将不同的事物和处理分离.而层数的多少决定了模型的合理性和复杂度   

    

  三层是一个比较平衡的数目,所以无论是MVC还是户界面/商业逻辑/数据库都一样,包括数据库里的三层模式也一样,都是对复杂度和合理性的平衡考虑.   

    

  分层包括两种方法,一种是横向的,很好理解.就是不同的层负责不同的功能和业务,相互间的通信并不完全自由,而是遵从上下级的关系,不能越级,只能与临近的层通信.形象些的说法就是球层,内部对外部是完全屏蔽的.   

    

  第二种就是纵向的,即不同的层有不同的逻辑,三者是同级别的并行关系,按照一定的协议或逻辑来通信协作.三者构成了一个三角形的关系.   

    

  之后就是针对不同的需求合理的分析而已.任何东西都不能一味的死学,完全遵从所谓的规范的.

dawugui 2009-01-12

打赏
举报

[Quote=引用楼主 shuaifujian 的帖子:]
靠发现这边高手还真多我现在搞的是C++模拟开发数据库除了在学校里面学的到工作中几乎没用到对于C/s模式开发我在网上看到有两层模式和三层模式对于这两种模式网上没有说的清楚，我的理解是两层模式就是前端的应用层对数据库直接操作，而三层模式则加了个逻辑处理。我现在打算这样做把所有的数据处理放在类里面作为中间数据处理的一层不知哪位高人能说的清楚点。
注:这个加分怎么加啊看到你们回贴我想给你们加分不知道如何加：）[/Quote]

三层结构的概念     

  在传统的Client   /   Server应用中，也存在着上述同样的问题，多层结构的应用正是在对C/S   结构的总结基础上产生的，并且也已经扩展到了B/S应用开发领域。   即将应用划分为三层(可以有更多层，但三层最常见):   用户界面层，商业逻辑层，数据库层。     

    

  用户界面层负责处理用户的输入和向用户的输出，但并不负责解释其含义(出于效率的考虑，它可能在向上传输用户输入前进行合法性验证)，这一层通常用前端工具(VB，VC，ASP等)开发;   

    

  商业逻辑层是上下两层的纽带，它建立实际的数据库连接，根据用户的请求生成SQL语句检索或更新数据库，并把结果返回给客户端，这一层通常以动态链接库的形式存在并注册到服务器的注册簿(Registry)中，它与客户端通讯的接口符合某一特定的组件标准(如COM，CORBA)，可以用任何支持这种标准的工具开发;   

    

  数据库层负责实际的数据存储和检索。   有了这样的结构，上面的问题迎刃而解:还是以考试系统中的合格标准为例，在客户端所有需要显示合格人员名单的地方，调用这样一个函数GetQualifiedList，至于这个函数如何编写，如何与数据库打交道，以至访问的是何种数据库都与其无关(你一定有过这样的经历，在一种数据库系统上运行得很好的SQL语句，有时换到另一种数据库系统上必须加以修改);   在中间层DLL中实现这个GetQualifiedList函数，如果用户对"合格"的定义变了，只需要修改这个函数就可以了，只要此函数的入口参数和返回内容不变，在客户端不需作任何改动。在这里，我们看到了面向对象编程的特性之一封装性的优点，而这一点在开发大型应用时尤其有用--我们可以把开发人员分成两组，一组负责开发界面层，另一组负责开发商业逻辑层，双方只要按照事先商定的函数接口，并行地开发就可以，而不必向从前那样，后面的工作必须等前面的工作完成后才能开始。当然，这样的开发模式需要很好的项目协调和文档作支持。     

    

  你也许会问，如果我把这些函数些在一个单独的文件中，再在需要调用的地方把它包含进来，不是同样能达到目的吗?   第一，这种方法效率不高，无论你把这些函数分散到多少个文件中，当你需要调用其中一个时，总会包含进一些实际上并不需要的函数，这无疑加重了服务器的负担，对服务器性能要求较高的Web应用尤其如此。   而DLL只在需要时才调入内存且只调入需要的函数，并且多个应用程序实例可以共享同一个DLL实例；第二，设想一个员工，有20个属性(工号，姓名，年龄，性别......)，现在给定某工号，要求返回此员工所有信息。此时如果单纯用函数，只能定义20个全局变量，在函数中改变这些变量值，或者定义一个有20个传参(by   reference)参数的函数。显然，第一种方法很麻烦而一旦增加一个属性后一种方法就需要更改函数接口。而在一个对象里，既包含成员方法(即函数和过程)，也包括成员属性。如果我们采用对象的方法，则在函数中只需要改变对象的属性，在函数外可以直接引用改变了的对象属性值。   这种方法有些类似第一种方法，但1.属性值无需在函数外逐一说明；2.这些属性值只属于对象，与对象无关的代码不会无意地改变属性值；3.一旦对象被释放，这些值会被一起释放。

shuaifujian 2009-01-11

打赏
举报

能不能再说的详细点。。。

水族杰纶 2009-01-11

打赏
举报

我们用三层结构主要是使项目结构更清楚，分工更明确，有利于后期的维护和升级． 



三层结构包含:表示层(USL),业务逻辑层(BLL),数据访问层(DAL) 



1：数据数据访问层:主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不 



是指原始数据，也就是说，是对数据的操作，而不是数据库,具体为业务逻辑层或表示层提供数据服务． 



2：业务逻辑层:主要是针对具体的问题的操作，也可以理解成对数据层的操作,对数据业务逻 



辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。 



3：表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成 



:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地 



提供服务。 



具体的区分方法 



1：数据数据访问层:主要看你的数据层里面有没有包含逻辑处理，实际上他的各个函数主要完成 



各个对数据文件的操作。而不必管其他操作。 



2：业务逻辑层:主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。 



3：表示层:主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。