春天走了，夏天来了，炎热的办公区还是没有给空调，真是热死人了，不过工作还得做，领导说我们下一个产品要采用最新的技术，要三层架构，要……，要……我都快睡着了，被领导一拳击醒，睁着不知所以然的眼睛看着他的吐沫星子喷溅而来，“三层架构……”，领导恶狠狠的说。以前也听说过三层架构，什么Java中的Struts，.NET中的Transaction Server\Remote data Services……太混乱了，我不知道从什么地方下手，算了，领导的话就是圣旨。从会议室回到座位，思量很久……三层架构的好处肯定是有的，实现了表示、数据、逻辑的分开，减少了耦合度，更加灵活，适于维护，可开发成本提高了，尤其是我们部门没人做过呀。别的部门听说有人做过或正在做，听看过的人回来说也是一踏糊涂，为了不蹈他人覆辙，我决定好好规划一下。这样吧，大家就在这个帖子里讨论一下吧，有谁搞过三层架构，希望理论知识就不要多谈了，谈谈大家是怎么实施的。从最基本的谈起，如何做需求与设计的，程序的架构如何搭建起来的（最好精到文件夹、包、类的划分），人员分工如何布置……如果谁有做过的例子更好，可以给我发一份，其他人想要的也可以留下电子邮件地址。我的电子邮件地址：[email protected]
(注：如果没什么意见或看法就说点别的，不要“up”“支持”“关注”……什么的，搞的太乱）
再次对各位的到来表示感谢，日安！
(注：如果没什么意见或看法就说点别的，不要“up”“支持”“关注”……什么的，搞的太乱）
再次对各位的到来表示感谢，日安！
留个妹儿:[email protected]
留个妹儿:[email protected]
http://www.v155.com/bbs/Dispbbs.asp?BoardID=12&replyID=1443&id=415&skin=0
其实个人觉得三层主要是一种实现理念,为了以后维护和扩展方便,不一定什么必须写在那个层,实现还是有一定灵活性的.本版以前有个三层的贴子,楼主看看吧.
传统两层结构 在过去应用系统开发过程中，CLIENT/SERVER体系结构得到了广泛的应用 。其特点是，应用程序逻辑通常分布在客户和服务器两端，客户端发出数据资源访问请求，服务器端将结果返回客户端。但CLIENT/SERVER结构存在着很多体系结构上的问题，比如：当客户端数目激增时，服务器端的性能会因为负载过重而大大衰减；一旦应用的需求发生变化，客户端和服务器端的应用程序都需要进行修改，给应用维护和升级带来了极大的不便；大量的数据传输增加了网络的负载等等。 三层结构介绍 所谓三层体系结构，是在客户端与数据库之间加入了一个"中间层"，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。 三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。 ASP.net只是.net中的一部分。它最大的优点除了是编译执行速度快外，我觉得最大的优点是页面和代码分离的编写方式（效果就象DELPHI里的FORM设计界面和处理代码分离一样），对我们这些惯使RAD工具的人来说不啻是个福音。再加上.net库提供的支持事件的各种WEB控件，和以前编写网页方式相比可谓是一场革命。随着分布式对象技术的逐渐成熟，多层分布式应用体系结构得到了越来越多的应用。应用系统只有向多层分布式转变，才能最终解决CLIENT/SERVER结构存在的问题。在多层架构下，应用可以分布在不同的系统平台上，通过分布式技术实现异构平台间对象的相互通信。将应用系统集成于分布式系统之上，能极大地提高系统的可扩展性。 在多层分布式应用中，在客户端和服务器之间加入了一层或多层应用服务程序，这种程序称为"应用服务器"。开发人员可以将应用的商业逻辑放在中间层应用服务器上，把应用的业务逻辑与用户界面分开。在保证客户端功能的前提下，为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码，只需要对中间层应用服务器进行修改，而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作。 Microsoft.NET 为三层结构做的准备 Microsoft .NET Framework是微软推出的一套下一代开发平台。.NET 基于开发人员的角度来说它是一个公共平台的类库(FCL)，包含了近100 个命名空间（namespace）的近5000个类，想想看这是多的强大，还包括一个公共语言运行库(CLR)。因为只要符合.NET的公共运行规范(CLS的语言都可以 使用它提供的强大的类，并编译为微软的中间语言（MSIL），在其他的应用中就可以当作一个组件来调用。同时享受公共运行库带来的一切好处： 垃圾自动回收(GC)、实时编译(JIT)、跨语言互动、跨平台。 .NET 还可比喻是操作系统提供给开发人员的面向对像的API。 ASP.net是.net中的一部分。它最大的优点除了是编译执行速度快外，我觉得最大的优点是页面和代码分离的编写方式，再加上.net库提供的支持事件的各种WEB控件，以及.NET公共平台的类库(FCL)，和以前编写网页方式相比可谓是一场革命。 用ASP.NET部署三层架构 ASP.NET可以使用.NET平台快速方便的部署三层架构。ASP.NET革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#,VB,J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名控件可以方便的使用自己定义的组件。显示层放在ASP页面中，数据库操作和逻辑层用组件来实现，这样就很方便的实现了三层架构。 下面分别就各层的实现举个制作留言簿的小例子。 我们首先在sqlserver数据库中建一个数据库GestDB,在GestDB中建表：Guestbook
Create table Geustbook(id int(4) unique not null,name varchar(20),
content text, Primary key id);
第一步：打开VS.NET，点击文件－》新建－》空白解决方案，在弹出的新建项目中选择Visal C#项目，模板选择ASP.NET Web应用程序.在位置处给本方案命名为geustbook.如下图所示。 第二步：建数据库访问控件。单击上图的"确定"。在窗口右边的 "解决方案资源管理器"中右击"解决方案"guestbook""选择"添加"->"新建项目"，弹出如下窗口，如图模板选择类库，填写名称，位置。注意该类库理论上与留言簿的工程是没有关系的，所以存储位置可以任意。 第三步：建立逻辑处理层。同第二步，建立另一个控件BusinessLayer。此控件用来调用数据库控件，封装留言簿所有的逻辑处理。如下图所示。 第四步：关于引用。因为BUSINESSLAYER要用到系统的WEB控件和刚才建的DBLayer，所以必须把二者添加引用。右键点击BUSINESSLAYER的"引用"，选择.NET的"System.web.dll"双击选中 然后再点项目的"DBLayer"双击选中。 第五步：把GUESTBOOK ASP.NET项目跟逻辑层联系起来，同样使用添加引用。注意：在BUSINESSLAYER已经引用过DBLAYER，在GUESTBOOK处只需引用BUSINESSLAYER就可以了。 现在你的GUESTBOOK解决方案资源管理器应该是如下图所示： 如果不是的话，请检查一下上面的步骤哪里是否出错。 通过上述步骤，就已经成功部署了ASP.NET的三层架构。在guestbook这一层我们放置应用显示的ASP页面，在BusinessLayer层，我们把所有的业务逻辑代码在该层实现。DataLayer层主要处理数据库的操作，供BusinessLayer层调用。 只要在各个层中实现具体的类就可以成功实施三层结构的应用程序了。 总结: 本文简要描述了三层架构的软件体系思想，通过一个留言簿的例子主要介绍了用MS.NET部署三层结构的具体实现方法。
说白了。其实就是参数调用。来回引用。多转圈多绕。但这样的确好。尤其对企业因为安全。偶合效果明显。如果还想具体知道点什么：MSN:[email protected]聊了。
能把你写的给我发一份吗？最好有图啊！先谢谢了！
[email protected]
想heilong05兄弟学习！
能把你写的给我发一份吗？最好有图啊!先谢谢了！
麻烦您给上面的那位兄弟发一份的时候，能不能顺便也给我来一份呢？
先谢谢了！
[email protected]
Email: [email protected]
不要以为层多就是开发成本高了..细致点便于业务的拆分理解.各层的作用明确..我们公司大致有5-7层呢~~稍微说说
实体层..都是一些后缀为xsd的文件..里面存储的都是一些表的数据结构
工厂层..数据工厂..
接口层..不同接口的调用.与数据工厂一起使用
实现层..所有与数据库有关的都再这里.与业务逻辑无关
规则层..规则.逻辑判断.以及组合dataset等等
表示层..就是aspx页面一层一层的调用..很清晰吧..嘻嘻我们还有一个DateBase的管理..所有的数据库里面的东西.比如存储过程,表和视图的SQL语句希望能给点帮助
可否给个有图的网址，谢谢了！
具体使用什么架构应该根据实际情况来说的
我做的前一个项目原来是准备使用仿Duwamish的,但是完全采用这种模式也不是完全好的,例如对于事务的处理就不大方便了,所以在虽然那个项目开始的时候定的基调是按照Duwamish的模式来开发,但到后来还是有不少地方用的是其他的方法来解决的.
不知道是不是我理解有误,反正感觉就是不能尽信模式,有的时候还是要结合来使用的.
我对架构只是了解一点
如果有什么好书，请多多给我介绍啊
谢谢了
Email:[email protected]
如果项目分多期进行，每期用不同的数据库时建议使用至少4层的结构。
sql语句处理上单独写在公共类中，更换数据库时可以只改变这一层和数据库处理层就可以了。
有交流和指教的朋友来一起聊聊！
QQ：12074814；妹儿：[email protected]
my mail: [email protected]
blog.csdn.net/foolnet
我这里把Java的东西给搬了进来，还算结构清晰,类似Struts！