现抢个位置
  回复  引用  查看    

这不是三层的问题, 这是你们项目的问题,什么都确定不了,,别说是三层,,你不用三层还不是照样不好弄.
  回复  引用    

@leleroyn

但是基本上大的需求是定下来了，以后的添加功能什么的是避免不了的，到最后还是要面临第一个问题，而且我提的这些问题相信大多数人都会遇到。
  回复  引用  查看    

呵呵 同样迷茫
  回复  引用    

我们一直说的三层架构是指逻辑分层，物理上的分层往往是指另一回事。
  回复  引用  查看    

--引用--------------------------------------------------
赵俊: @leleroyn
<br>
但是基本上大的需求是定下来了，以后的添加功能什么的是避免不了的，到最后还是要面临第一个问题，而且我提的这些问题相信大多数人都会遇到。
--------------------------------------------------------

  回复  引用  查看    

如果这样的话，我觉得测试驱动开发是个不错的选择，你给他把ui先定好，ui几乎可以反应用户的所有需求，那么从ui到逻辑到数据层层往下，也会容易一点，最主要的是可以利用ui引导并完善了用户的需求。
  回复  引用  查看    

--引用--------------------------------------------------

Jeffrey Zhao: 我们一直说的三层架构是指逻辑分层，物理上的分层往往是指另一回事。

--------------------------------------------------------

那怎么把逻辑分层跟物理上的分层结合起来呢？能不能指点一下。

@Windie Chai（笑煞天）
不是很懂，不过感觉你说的不是三层架构的事情。
  回复  引用  查看    

掌握住用户真正的需求才是你这个项目启动设计的前提条件。

如果用户对系统没有太多的概念，你可以先用Visio或者其他设计工具先Show一下你们的想法。（包括用户界面设计方案，以及业务流程，功能等方面）

当用户有了明确的需求确认后，再动手也不迟。

要不然，你们开发的系统肯定不是用户所需要的。

  回复  引用    

分层不是指分成三个dll，如果要做负载均衡也有很多成熟方案可以参考下
  回复  引用  查看    

你看一下架构和设计模式相关的书 对你比较有益处
  回复  引用    

现在一个大的项目不，用多层结构，还真是没法做下去。
到系统维护时，才知道多层结构的好处。
我们公司之前的用的vb6.0开发的系统，很多代码全部揉在一起，后来改起来，简直要人命。
  回复  引用  查看    

可能是你缺乏项目经验，其实这个很好做。你不用实体类就用dataset之类的数据集，要做到多台服务器负载均衡，asp.net可能要做4层了，浏览器和IIS＋提供服务层，或浏览器＋iis＋数据库三层
  回复  引用    

和我上一个项目有点像,客户需求不明确,改起来从数据库,实体,业务逻辑,UI一个一个来改,真要命,,,
  回复  引用  查看    

@横刀天笑

负载均衡我看过一点，但是好像不符合我的需求，我是想把他们结合起来用，比如把三层分在不同的服务器上面。

@hahaer

设计模式我研究过一阵，而且我现在最大的问题不在三层之间的解耦上面。

@kingly

三层架构不是不能传递dataset这种强类型吗？这会造成三层之间的强耦合的？
  回复  引用  查看    

三层通常指实体层，逻辑层，表现层。你上面所说的分布在不同的服务器上，这个其实就是整个系统部署结构的问题。
对于扩展，需求不定，设计出来的以后有你改的了。
  回复  引用  查看    

在客户数据表及字段需求多变的时候,针对不同的表建立类,类与表是一一对应的,也就是说客户要对数据字段变动,我们只需要去更变表及相对应的类就要可以了. 这是数据层.但是如果他的业务需求也要变的话,这个```建议先把合同写好了再开工吧!~
  回复  引用  查看    

感觉楼主的观念比较模糊
1，首先，物理分层，和一般的逻辑分层不同
2，谁说一定要实体类呢？
3，没必要每层都设计成web server，性能会有问题
4，你需求没确定，那你做什么？需求都没确定，你就想实体类的问题了，是不是有点那个？？？
5，你还是安心写代码，这些问题一般都是有架构师该考虑的
个人见解，见笑
  回复  引用  查看    

--引用--------------------------------------------------
王孟军！: 感觉楼主的观念比较模糊
1，首先，物理分层，和一般的逻辑分层不同
2，谁说一定要实体类呢？
3，没必要每层都设计成web server，性能会有问题
4，你需求没确定，那你做什么？需求都没确定，你就想实体类的问题了，是不是有点那个？？？
5，你还是安心写代码，这些问题一般都是有架构师该考虑的
个人见解，见笑
--------------------------------------------------------
你的话让我更迷茫了，都是反问，还有很多小公司没有架构师的，都是兼职的，比如我们公司，这些都是一般人一开始使用架构的时候都会遇到的问题。
  回复  引用  查看    

如果是你的实体的数据项定不下来的话，采用更加灵活的数据结构吧。例如：
class Entity:Dictionary<string,object>

序列化/反序列化方法要自定义

  回复  引用  查看    

请先确定需求,没有需求 什么都干不了,需求是项目的跟本.

就算没有绝对的需求,那相对的需求也得有吧.就因为需求多变,才会有分层设计.
  回复  引用  查看    

建议楼主先模仿个项目，慢慢就会明白了，个人感觉你的问题问的有点莫名其妙，可能是我老了~
  回复  引用  查看    

UI层和逻辑层之间一般不用Web service，都是同一个Appdomain中的，速度快而且方便。
UI层和逻辑层之间用远程调用或者Web service的也不是没有，但有很多缺陷，对性能和开发工作量都有很大影响，一般的站点不会采用。当初的EJB就是一个例子，滥用EJB的结果是导致了JAVA世界中轻量级容器的兴起，EJB变成了笨重的代名词
  回复  引用  查看    

还有，楼主肯定有项目经验，先不要去管那么多，你已经把自己限进去了~

哈哈~你们项目经理是嘛事都不管的吧~


  回复  引用  查看    

负载均衡我看过一点，但是好像不符合我的需求，我是想把他们结合起来用，比如把三层分在不同的服务器上面。

>>
客户端 肯定不需要 服务器的 呵呵

首先，楼主在概念上有很多不清楚的地方，其实，你就是没有做过这样的系统，所以感觉比较迷茫，如果有过一个这样的实际的系统作为参考，相信楼主就能轻松不少了。

其次，webservice 作为数据层 是可行的，这样的好处是可以单独的发布在一个webserver上面，不用和dbserver 保持同一台电脑。也算是简单的负载均衡了，当然和多台dbserver，多台webserver 肯定是不一样的。

不过，webservice 也有很多地方 有它的缺陷，首先不能通过二进制而只能通过http的协议就是一方面，其次，在数据传输方面，大多数的时候都要通过序列化和反序列化，这样要有一定的开销。而且，这样就要求你的实体在设计的时候尽量弄成贫血模型的，也就是瘦实体，这样，传输的代价相对要少一些。（貌似还不支持泛型）。

再其次，可以适当的考虑反射或者cache等，这样能有效缓解webservice的臃肿。

  回复  引用  查看    

三层!=不用改阿
任何设计方法都不能完全解决变更，只是改多改少而已嘛
用一层架构和三层比就知道哪个好了，哈
  回复  引用  查看    

@wit

我的项目经理不是很清楚架构方面的知识，所以和我一样不能理解物理分层跟逻辑分层的概念，结果使用了三层架构以后发现了越来越多的问题。
  回复  引用  查看    

感觉现在有很大的误解，实体就是单纯的表的映射，当然这么说也没有错，可是如果把实体考虑成领域模型，那么实体和表之间肯定会有出入，而这样的出入一般是通过映射解决的。

实体作为领域模型，更应该关注的是领域本身，这也是领域驱动的根本！

  回复  引用  查看    

@xiao_p
谢谢！你的讲解让我懂了一点，我现在就是把最后一层（解析Sql语句的接口层）做成了Web Service，和数据库放在一台服务器上面，其它的就没有办法了。
  回复  引用  查看    

貌似楼主的应该是个cs的程序了

你就把webservice 作为一个 提供者，webservice的主要作用就是帮助你增删改差数据用的。

这样你就应该能明白了。

还有，webservice 部署的时候可以和dbserver 不在同一台电脑上的！
因为现在的dbserver 貌似 任务都比较多！ dbserver 都比较累 ！ :-)

  回复  引用  查看    

1、没有说明项目是基于什么模式。C/S？B/S？
2、没有说明项目的网络适用范围。广域网？局域网？
3、没有说明项目的性能需求。多个服务器均衡负载有很多种方式，上面2条+性能需求的不同导致的选择也不同。
4、三层架构通俗的说就是：表现层，逻辑层，数据层。
一般来说，表现层用于展示业务界面，接受业务操作以及处理业务界面的关系，
逻辑层用来接受业务数据，并在业务范围内处理业务数据
数据层则用来持久化数据。

这三层的关系与模式的选择有关，甚至于每一层的容器的选择也有关。
例如C/S模式，逻辑层往往被定义为应用服务层，那么就必然存在一个应用服务器，于是就在逻辑上出现了逻辑层而在物理上出现了应用服务器。对于普通的项目来说，我们往往把业务逻辑与数据访问紧密结合起来，因此逻辑层和数据层也就都部署在应用服务器上，所以这种情况下的物理分层也就两层，表现和应用服务。

对于业务实体，项目的需求与业务实体的选择息息相关。例如：C/S项目中，在应用服务器存在的情况下，客户端是不能直接访问数据库的，而是必须把数据传递给应用服务器，由应用服务器来处理并决定如何持久化数据。那么就要考虑到所选择的业务实体是能够适合网络传输的，并能记录用户对数据的编辑的状态的。否则，当数据被传递给应用服务时，应用服务器却不知道如何持久化数据。
而在B/S项目中，这样的考虑显得就不是很重要。更特殊的情况就是，比如延迟加载，这是很多实体所具备的能力。但是这个能力对于C/S模式就不能使用。因为当数据被传递到客户端时，与数据库的链接是断开的。而在C/S模式下维持一个数据库链接几乎是一项不可能的任务。

最后，是否选择WS与项目的适用网络范围有关。局域网没有必要使用WS，如果要用反而降低性能。WS是用来与外部或异构系统交互而使用的。
  回复  引用    

lz先看看.net petshop，然后再考虑分层，你对层的理解是错误的
  回复  引用    

“由于这个项目的客户需求说需要做到分担负载，于是项目经理就要求三个层必须要安装在不同的服务器上面”

哈哈，你们的项目经理也够可以的，如果访问量不是特别高，在物理上的部署只需Web服务器+数据库。要负载均衡就在Web服务器之间进行就行了
  回复  引用  查看    

其实很多人对三层都有理解上的错误，或者是滥用三层。其实三层的一个主要目标就是隔离变化点——1、数据库之间的切换 2、B/S模式&C/S模式之间的切换。但实际项目中有这些需求的少之又少。
  回复  引用  查看    

你的项目经理也好像一般啊！只能说明你们项目的前期设计有问题！
而且又不是除了三层结构就不能解决问题！
  回复  引用  查看    

我觉得还是要灵活点儿处理比较好.
如果硬要用所谓的"三层架构"的话,个人认为有两种方法可以参考一下:
1.层与层之间的传输的时候不一定非要用实体来传输吧?用DataSet或者DataTable来传递应该也是可以的吧?实际的开发过程中,很有可能用户一会儿说要这样实现,等你改好,用户又觉得不好,又要改回去....这个是最郁闷的.
2.不知道可不可以用ORM,如NBear之类的东东,这样数据表改变了的话,用工具根据数据表生成实体类,再修改一下BLL应该是可以的吧?这个只是我的想法而已,不对的地方就当我没说.

另外,三层我到现在也没有体会到他真正有什么好处,虽然看起来是规范了一些.


个人比较SB的看法,说得不对还忘口下留情.
  回复  引用  查看    

1.实体只是可序列化的普通类，各层之间的传递在同一个机子里是用引用，不同机子间是序列化和反序列化， 这个.NET会搞定，你不用担心
2.WebService的使用，不是你把各层放在不同的服务器上就是负载平衡了……WebService因为有了WCF你也能比较傻瓜地完成一下，不用管具体实现
3.到底怎么分配，一个可行的方案是看你的业务层有几个接口，每个接口放在一台服务器上，这样不就分流了嘛~
4.WebService无所谓臃肿的说法，你放在那里当个方法也是去调用，你做个WebService也是调用，一样的理念
5.需求变化是没法控制的，你无论分不分层都一样

具体是不是分层要看实际情况，如果不分层，像上面说的每个接口放一台服务器上就很难做到了
  回复  引用  查看    

很久前拙文.
http://www.cnblogs.com/jiangshaofen/archive/2007/12/10/989928.html
  回复  引用  查看    

楼主啊，你干活又不是在学校里考试，架构怎么做不是死的。感觉你对层的理解有误区，建议先看看petshop
  回复  引用  查看    

谁说分层可以节省开发时间？节省人力物理了？？？
和盖楼一样，层越多越难盖，需要人力物理也越大，这是必然的

为什么要分层？
便于维护、还是便于维护（我们现在改代码量很大怎么好维护了？你不是说分层人力投入更大？）
的确分层投入人力大，但是我给你说一个例子
其实分层和把一个10000行的函数优化或重构为 n 个子函数的道理是一样的
编程最可怕的不是劳动量大，而是代码不好看，难看懂，没法改，你明白了吧
分层的意义也在于此。体力劳动量在大，逻辑关系清晰修改起来只是党务点时间、
而如果代码乱没法改，没法看，那就连改都没法改了；

以下是你的问题：
1）答了上边

2) 如果是和其他应用程序交互，实体层一般分为几种类型（自己用的，给别人的）传递时需要把“自己用的”转换为“给别人的”按需转换比如人家要 3个字段，你给了 6个就是不太好了。

3) 负载？？也用不着拆分程序啊；（你一定没了解需求或那里听错了，否则你那个“项目经理” 就是脑子灌水了）

4) 如果说类似 petshop 的，前些时日做过一个 【表现 > webserver > 逻辑处理 > 数据处理】 是为了，编译第3方二次开发用的 webserver 服务端实体类型分为共享的，自用的，共享的主要给【表现】用，自用的给 webserver 后面那些用；不过你这种要层层都分的视乎没有什么意义啊；


补充：
软件开发中的所谓“体力劳动”多半是指，没什么逻辑的（如实体类中的属性，界面上的排放的一个控件等等 ）这些东西其实原则上都可以用代码生成器生成的；生成器可以是开发时的（就是大家经常用的代码生成器），也可以是运行时的 （这个就需要自己根据不同业务开发了，这东西可大可小如动态生成调用webserver 的代理类就是一种比较简单的代码生成机制 ） 实体代码怎么也比动态配置代码性能上好很多（注：博主最好现在不要去搞什么运行时代码生成器，还是把基本知识在深入了解一些吧）
  回复  引用  查看    

有些麻烦
  回复  引用    

看你说得真的是很迷茫了 呵呵
  回复  引用  查看    

dbserver+webservice
然后webservice提供数据的增删改查。。。
bs+cs
然后定义模型（相当于visio的功能）

我们的系统是这样子地。。。当然里面的细节就因人而异了。。
  回复  引用    

--引用--------------------------------------------------
昉: 其实很多人对三层都有理解上的错误，或者是滥用三层。其实三层的一个主要目标就是隔离变化点——1、数据库之间的切换 2、B/S模式&amp;C/S模式之间的切换。但实际项目中有这些需求的少之又少。
--------------------------------------------------------
有些需求是用户硬要这样做的，特别是那种有一点“懂”的用户，做项目的有时也没有办法，他们说如果有一台服务器当机了，其它的服务器可以平滑的过度。
  回复  引用  查看    

好多人让我先看看petshop，我就看了petshop以后迷茫的，不过还是要谢谢大家，我只能慢慢理解了！
  回复  引用  查看    

很多新人，包括自己不能理解分层
是因为没能真正理解三层，也没有维护过大型项目
所以感觉分层带给的就是麻烦
我想这个需要经验来一点点的去理解
不管文章介绍的多好，都不能切切实实感受到多层的好处
当然我们要了解多层的方方面面，在项目实践中用心去体会去思考
  回复  引用  查看    

不要因三层而三层，适合自己的才是最好的，要有创新！
  回复  引用  查看    

三层有优点也有缺点。
优点不多说了，容易维护。缺点就是一旦需求改动，三层都需要该，工作量一下大了3倍（表改了，你实体不改么？实体改了，你逻辑不改么？逻辑改了，你UI不需要变么？）。
当然，对于改动来说，三层结构清晰，易于理解和维护，优点远远大于缺点。
我们可以利用代码生成器等工具将改变减少到最小，比如实体映射都可以采用VS自带的工具或者NHIbernate等。其他的，只需要改下方法，调用数据层的方法即可。
既然对三层不是很熟悉，应该给自己一段时间学习，千万不要用自己没掌握的技术，要不然很容易造成项目的失败。
我自己的项目是用AEF+linq做数据层的，利用VS工具来生成实体映射，至于增删改，用linq就可以了。业务逻辑层就是对外发布Endpoint，用VS WCF自动生成代理，实现也只是简单调用数据层。界面比较麻烦，用的是WPF/Silverlight，基本上80%的时间花在这上面。（其他2层的改动很容易）

楼主可以先稳固需求（签合同），然后一步步做。其他可以边学边做。如果真觉得头大的话，就不要考虑用什么设计模式去发展扩展性，只要能达到软件质量就OK得了。
  回复  引用  查看    

如果按这么来说的话，确实是要分层的

不过要进行负载分担的话，就要使用多层分布式会比较好

项目也会因此而变得复杂
  回复  引用  查看    

不要为了分层而分层，实际应用中注意把握一个度
  回复  引用  查看    

--引用--------------------------------------------------
王孟军！: 感觉楼主的观念比较模糊
1，首先，物理分层，和一般的逻辑分层不同
2，谁说一定要实体类呢？
3，没必要每层都设计成web server，性能会有问题
4，你需求没确定，那你做什么？需求都没确定，你就想实体类的问题了，是不是有点那个？？？
5，你还是安心写代码，这些问题一般都是有架构师该考虑的
个人见解，见笑
--------------------------------------------------------
说得好!
  回复  引用  查看    

用remoting吧,可以解决远程调用问题
  回复  引用  查看    

谁说三层就不能用dataset,datatable了?它们也是数据库无关的数据结构. java中没有它们,所以大家只能了hibernate了.呵呵.
  回复  引用  查看    

--引用--------------------------------------------------
王孟军！: 感觉楼主的观念比较模糊
1，首先，物理分层，和一般的逻辑分层不同
2，谁说一定要实体类呢？
3，没必要每层都设计成web server，性能会有问题
4，你需求没确定，那你做什么？需求都没确定，你就想实体类的问题了，是不是有点那个？？？
5，你还是安心写代码，这些问题一般都是有架构师该考虑的
个人见解，见笑
--------------------------------------------------------

说的好！

我的愚见如下：
1. 如果非要分布式应用，就用Remoting吧，否则会对性能产生毁灭性的损害
2. 客户的需求不明确，就说明用的架构一定要经得起折腾，能适应频繁的修改
3. web service是用来提供服务的，我一般是把它和Facade模式协同应用，使一次服务的调用能够完成粒度尽量大的操作，在应用中web service的延时是非常恐怖的，不可小觑（AJAX除外，比较是异步的）
4. Petshop 架构只适合学习，绝不适合应用，开发效率低，即使是用代码生成器
5. 最后，不要为了层而层，不要为了模式而模式，没有什么最好的技术，只有最适合的
  回复  引用  查看    

以前我也产生过类似的迷茫，主要是还没真正的领悟三层。

三层只是一个统称，所谓三层并不一定只是三层也可能是4、5、N层。比如还会有缓存层、事务层之类的。

三层只是设计模式的一种应用，就好功夫一样，没有一种是不败的。适时的选择合适的方法才是重要的，生搬硬套是自寻烦恼。

问1：客户的需求很模糊，这就带来了数据库设计的困难，三层架构都说用实体层来进行数据传输，那么这么实体层应该怎么设计，其它层怎么设计（你的接口层定不下来），如果以后添加功能就得先改实体层然后一层层的修改？

答：设计是个迭代的过程，要确定客户的需求需要相当的技巧和经验。多出模型、多和用户沟通才是正确的。在确定需求在做设计，做设计的时候争取最大化客户需求，最小化功能设计，这样才能有良好的扩展。


问2：还是实体层，如果我其它两层设计成了Web Service那么这个层怎么设计，怎么传递？

答：三层不一定用实体层。如果一定要应用实体层在Web Service中可以把实体对象作为数组或XML传递，在使用时序列化。


问3：由于这个项目的客户需求说需要做到分担负载，于是项目经理就要求三个层必须要安装在不同的服务器上面，那么按照园子里面大多数人的想法（比如PetShop）每一层建不同的类库，那该怎么放在不同的服务器上面，他们之间怎么互相访问，如果其中一层还想分在不用的服务器上面呢？

答：分担负载有很多不同的方法，例如可以把数据库和逻辑处理层分开，再把前台页面放在一个独立的服务器。在程序设计上进行适当的接口编程。


问4：如果每一层设计成了Web Service，哪改怎么设计？怎么传实体层？到最后这么Web Service会不会变的很臃肿，好像看了园子里面很多资料都没有发现Web Service在三层架构中应用的例子，而且我试了一下发现Web Service不能返回工厂模式生成的接口，提示不能序列化接口。

答：每一层设计成Web Service不是不可以。具体要怎么就要看需求了。传送实体层前面一经说过，XML或数组、JSON等，方法很多。实践证明不能序列化是程序问题。另外工厂和调用生成接口的程序必须在一个服务器上。

over


  回复  引用  查看    

首先有些需求是挖掘出来的,客户在计划一个项目的时候,大多数只是有一个初略的想法,并没有具体的,详细的东西,所以就靠需求调研人员与客户有效的沟通,结合以往项目经验,从最终使用用户角度出发(也就是用例驱动)找到他们想需要的,然后抽象出概念模型,制作系统原形,此时再与客户沟通,他的最初想法也就会慢慢的成熟或者成型,如此反复,叠代,增量的进行,我想系统会朝着一个可控制的,成功的方向迈进

  回复  引用  查看    

建议版主，看一下，CSLA.net框架，对分布式和可扩展性作了很好的支持，层间传递业务对象。支持webservice,remoting,COM+,WCF等主流通信方式，有一本书 Expert C# Business Object。看中文版第2版的。
  回复  引用    

看来需要用到WCF了！
  回复  引用    

物理分层就可以解决这个需求了
增加一台负载均衡服务器,数据库做双机热备份

1x 负载均衡
2x WebServer
2x DbServer
  回复  引用    

莫烦,万事开头难
  回复  引用