项目怎么改为分布式的

如何搭建分布式网站服务器，比如我有3台服务器ABC，需要搭建分布式服务。也就需要建立IIS 还由DNS WIN 服务器的 还有更改主机名 很麻烦的,这个需要专业的IT人员来操作的。

以下资料作为参考：

DNS轮循

首先介绍一个DNS系统:传统的DNS解析都是一个域名对应一个IP地址,但是通过DNS轮循技术(负载平衡技术)可以做到一个域名对应到多个IP 上. 这样大家难免就会问,这个技术有什么用呢?

DNS轮循是指将相同的域名解释到不同的IP，随机使用其中某台主机的技术,该项技术可以智能的调整网站的访问量到不同服务器上，减轻网站服务器的压力，实现负载匀衡如果您感觉到单一的主机已经不堪负载你网站日益增长的访问，那么建议您采用我们的DNS轮循技术。　

DNS轮循系统可以根据您的需求设置N台主机作为WEB服务器。目前已有越来多大型的WEB服务器使用DNS轮循来实现负载均衡，服务的分布规划更便捷，扩展性更好，从而提高了网站的稳定性和访问效率，那些大量数据文件请求的客户也得到了更快的响应。

DNS轮循还将给您的网站提供这样的改进，诸如您的网站的数据使用量一直处于不断的增长当中，当达到服务器资源运行瓶颈的情况

下，由于采用了DNS轮循技术，您只需要增加服务器数量就可以平滑升级，而且偶然故障或其他意外情况造成的损失得以避免，7×24小时可靠性的持续的运行

成为可能。

如果您真的希望自己的网站能够一直稳定的在线运行，尽量的减少宕机的比率，那么除了采用比较好的网站空间技术支持之外，还可以采用时代互联域名的DNS轮循功能来实现网站的永久在线负载平衡

负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其

他服务器的辅助。通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。均衡负载

能够平均分配客户请求到服务器列阵，籍此提供快速获取重要数据，解决大量并发访问服务问题。这种群集技术可以用最少的投资获得接近于大型主机的性能。

网络负载均衡的优点

第一，网络负载均衡能将传入的请求传播到多达32台服务器上，即可以使用最多32台服务器共同分担对外的网络请求服务。网络负载均衡技术保证即使是在负载很重的情况下，服务器也能做出快速响应

第二，网络负载均衡对外只需提供一个IP地址(或域名)

第三，当网络负载均衡中的一台或几台服务器不可用时，服务不会中断。网络负载均衡自动检测到服务器不可用时，能够迅速在剩余的

服务器中重新指派客户机通讯。这项保护措施能够帮助你为关键的业务程序提供不中断的服务，并可以根据网络访问量的增加来相应地增加网络负载均衡服务器的数

量

第四，网络负载均衡可在普通的计算机上实现。

网络负载均衡的实现过程

在Windows Server 2003中，网络负载均衡的应用程序包括Internet信息服务(IIS)、ISA

Server 2000防火墙与代理服务器、VPN虚拟专用网、终端服务器、Windows Media

Services(Windows视频点播、视频广播)等服务。同时，网络负载均衡有助于改善服务器的性能和可伸缩性，以满足不断增长的基于

Internet客户端的需求。

网络负载均衡可以让客户端用一个逻辑Internet名称和虚拟IP地址(又称群集IP地址)访问群集，同时保留每台计算机各自的名称。下面，我们将在两台安装Windows Server 2003的普通计算机上，介绍网络负载均衡的实现及应用。

这两台计算机中，一台计算机名称为A，IP地址为192.168.0.7另一台名为B，IP地址为192.168.0.8。

规划网络负载均衡专用虚拟IP地址为192.168.0.9。当正式应用时，客户机只需要使用IP地址192.168.0.9来访问服务器，网络服务均衡

会根据每台服务器的负载情况自动选择192.168.0.7或者192.168.0.8对外提供服务。具体实现过程如下：

在实现网络负载均衡的每一台计算机上，只能安装TCP/IP协议，不要安装任何其他的协议(如IPX协议或者NetBEUI协议)，这可以从“网络连接属性”中查看。

第一步，分别以管理员身份登录A机和B机，打开两台机的“本地连接”属性界面，勾选“此连接使用下列项目”中的“负载均衡”项并进入“属性”对话框，将IP地址都设为192.168.0.9(即负载均衡专用IP)，将子网掩码设置为255.255.255.0

第二步，分别进入A机和B机的“Internet协议(TCP/IP)”属性设置界面，点击“高级”按钮后，在弹出的“高级TCP/IP设置”界面中添加IP地址192.168.0.9和子网掩码设置为255.255.255.0。

第三步，退出两台计算机的“本地连接属性”窗口，耐心等一会儿让系统完成设置。

以后，如果这两台服务器不能满足需求，可以按以上步骤添加第三台、第四台计算机到网络负载均衡系统中以满足要求。

根据目前政策及业务规则，如您是广东电网公司的用电客户，分布式光伏发电项目上网方式变更受理资料如下：

【低压220（380）伏居民分布式光伏发电项目】

①分布式光伏发电项目业务变更申请表(表格由供电部门提供)；

②客户身份证明资料。

【低压220（380）伏非居民分布式光伏发电项目及高压10（20）千伏分布式光伏发电项目】

①分布式光伏发电项目业务变更申请表(表格由供电部门提供）；

②营业执照或组织机构代码证，法人代表身份证明资料；

③变更后的分布式光伏发电项目备案证。

业务办理注意事项：

①“自发自用、余电上网”模式的光伏项目允许变更为“全额上网”模式，但不得再变更回“自发自用、余电上网”模式。

②“全额上网”模式的光伏项目允许变更为“自发自用、余电上网”模式，但不得再变回“全额上网”模式。

③申请上网方式变更，需办理备案变更。居民客户重新申请备案，项目业主准备备案资料后统一交由供电部门代为办理，在获得当地能源主管部门备案批复后，重新签订相关协议；非居民客户由项目业主自行准备资料向当地能源主管部门备案，在获得当地能源主管部门备案证明文件后，提交供电企业，重新签订相关合同。

④变更前，我公司抄录上网电量、下网电量、光伏发电量的止码并向客户确认。

⑤变更生效时间由现场客户经理与客户协商确定，为了便于结算，通常约定月的起点，具体要以现场协商为准。

希望我们的回答你能对您有所帮助。

利用Spring Cloud构建起自我修复型分布式系统：

Spring Cloud Config Server

Spring Cloud Config Server能够提供一项具备横向扩展能力的集中式配置服务。它所使用的数据被保存在一套可插拔库层当中，后者目前能够支持本地存储、Git以及Subversion。通过利用一套版本控制系统作为配置存储方案，开发人员能够轻松实现版本与审计配置的内容调整。

Spring Cloud Bus

Spring Cloud Config Server是一套强大的配置分发机制，能够在保障一致性的前提下将配置内容分发到多个应用程序实例当中。然而根据其设计思路的限定，我们目前只能在应用程序启动时对其配置进行更新。在向Git中的某一属性发送新值时，我们需要以手动方式重启每个应用程序进程，从而保证该值被切实纳入应用当中。很明显，大家需要能够在无需重启的前提下完成对应用程序配置内容的更新工作。

Spring Cloud Netflix

Spring Cloud Netflix针对多种Netflix组件提供打包方案，其中包括Eureka、Ribbon、Hystrix以及Zuul。接下来我将分别对它们作出讲解。

Eureka是一套弹性服务注册实现方案。其中服务注册属于服务发现模式的一种实现机制。

1.性能和时延问题在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗：1）客户端需要对消息进行序列化，主要占用CPU计算资源。2）序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。3）客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。4）服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。5）服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。6）服务端将响应结果序列化，占用CPU计算资源。7）服务端将应答码流发送给客户端，占用网络带宽资源。8）客户端读取应答码流，反序列化成响应消息，占用CPU资源。通过分析我们发现，一个简单的本地方法调用，切换成远程服务调用之后，额外增加了很多处理流程，不仅占用大量的系统资源，同时增加了时延。一些复杂的应用会拆分成多个服务，形成服务调用链，如果服务化框架的性能比较差、服务调用时延也比较大，业务服务化之后的性能和时延将无法满足业务的性能需求。1.1　RPC框架高性能设计影响RPC框架性能的主要因素有三个。1）I/O调度模型：同步阻塞I/O（BIO）还是非阻塞I/O（NIO）。2）序列化框架的选择：文本协议、二进制协议或压缩二进制协议。3）线程调度模型：串行调度还是并行调度，锁竞争还是无锁化算法。1.I/O调度模型在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。I/O多路复用技术通过把多个I/O的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。JDK1.5_update10版本使用epoll替代了传统的select/poll，极大地提升了NIO通信的性能，它的工作原理如图1-1所示。图1-1　非阻塞I/O工作原理Netty是一个开源的高性能NIO通信框架：它的I/O线程NioEventLoop由于聚合了多路复用器Selector，可以同时并发处理成百上千个客户端Channel。由于读写操作都是非阻塞的，这就可以充分提升I/O线程的运行效率，避免由于频繁I/O阻塞导致的线程挂起。另外，由于Netty采用了异步通信模式，一个I/O线程可以并发处理N个客户端连接和读写操作，这从根本上解决了传统同步阻塞I/O一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。Netty被精心设计，提供了很多独特的性能提升特性，使它做到了在各种NIO框架中性能排名第一，它的性能优化措施总结如下。1）零拷贝：（1）Netty的接收和发送ByteBuffer采用DIRECTBUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAPBUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。（2）Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便地对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。（3）Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。2）内存池：随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty提供了基于内存池的缓冲区重用机制。性能测试表明，采用内存池的ByteBuf相比于朝生夕灭的ByteBuf，性能高23倍左右（性能数据与使用场景强相关）。3）无锁化的串行设计：在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导致性能的下降。为了尽可能地避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。为了尽可能提升性能，Netty采用了串行无锁化设计，在I/O线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。4）高效的并发编程：volatile的大量、正确使用；CAS和原子类的广泛使用；线程安全容器的使用；通过读写锁提升并发性能。2.高性能序列化框架影响序列化性能的关键因素总结如下。1）序列化后的码流大小（网络带宽的占用）。2）序列化&反序列化的性能（CPU资源占用）。3）是否支持跨语言（异构系统的对接和开发语言切换）。4）并发调用的性能表现：稳定性、线性增长、偶现的时延毛刺等。相比于JSON等文本协议，二进制序列化框架性能更优异，以Java原生序列化和Protobuf二进制序列化为例进行性能测试对比，结果如图1-2所示。图1-2　序列化性能测试对比数据在序列化框架的技术选型中，如无特殊要求，尽量选择性能更优的二进制序列化框架，码流是否压缩，则需要根据通信内容做灵活选择，对于图片、音频、有大量重复内容的文本文件（例如小说）可以采用码流压缩，常用的压缩算法包括GZip、Zig-Zag等。3.高性能的Reactor线程模型该模型的特点总结如下。1）有专门一个NIO线程：Acceptor线程用于监听服务端，接收客户端的TCP连接请求。2）网络I/O操作：读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送。3）1个NIO线程可以同时处理N条链路，但是1个链路只对应1个NIO线程，防止产生并发操作。由于Reactor模式使用的是异步非阻塞I/O，所有的I/O操作都不会导致阻塞，理论上一个线程可以独立处理所有I/O相关的操作，因此在绝大多数场景下，Reactor多线程模型都可以完全满足业务性能需求。Reactor线程调度模型的工作原理示意如图1-3所示。图1-3　高性能的Reactor线程调度模型1.2　业务最佳实践要保证高性能，单依靠分布式服务框架是不够的，还需要应用的配合，应用服务化高性能实践总结如下：1）能异步的尽可能使用异步或者并行服务调用，提升服务的吞吐量，有效降低服务调用时延。2）无论是NIO通信框架的线程池还是后端业务线程池，线程参数的配置必须合理。如果采用JDK默认的线程池，最大线程数建议不超过20个。因为JDK的线程池默认采用N个线程争用1个同步阻塞队列方式，当线程数过大时，会导致激烈的锁竞争，此时性能不仅不会提升，反而会下降。3）尽量减小要传输的码流大小，提升性能。本地调用时，由于在同一块堆内存中访问，参数大小对性能没有任何影响。跨进程通信时，往往传递的是个复杂对象，如果明确对方只使用其中的某几个字段或者某个对象引用，则不要把整个复杂对象都传递过去。举例，对象A持有8个基本类型的字段，2个复杂对象B和C。如果明确服务提供者只需要用到A聚合的C对象，则请求参数应该是C，而不是整个对象A。4）设置合适的客户端超时时间，防止业务高峰期因为服务端响应慢导致业务线程等应答时被阻塞，进而引起后续其他服务的消息在队列中排队，造成故障扩散。5）对于重要的服务，可以单独部署到独立的服务线程池中，与其他非核心服务做隔离，保障核心服务的高效运行。6）利用Docker等轻量级OS容器部署服务，对服务做物理资源层隔离，避免虚拟化之后导致的超过20%的性能损耗。7）设置合理的服务调度优先级，并根据线上性能监控数据做实时调整。2.事务一致性问题服务化之前，业务采用本地事务，多个本地SQL调用可以用一个大的事务块封装起来，如果某一个数据库操作发生异常，就可以将之前的SQL操作进行回滚，只有所有SQL操作全部成功，才最终提交，这就保证了事务强一致性，如图2-1所示。服务化之后，三个数据库操作可能被拆分到独立的三个数据库访问服务中，此时原来的本地SQL调用演变成了远程服务调用，事务一致性无法得到保证，如图2-2所示。图2-2　服务化之后引入分布式事务问题假如服务A和服务B调用成功，则A和B的SQL将会被提交，最后执行服务C，它的SQL操作失败，对于应用1消费者而言，服务A和服务B的相关SQL操作已经提交，服务C发生了回滚，这就导致事务不一致。从图2-2可以得知，服务化之后事务不一致主要是由服务分布式部署导致的，因此也被称为分布式事务问题。2.1　分布式事务设计方案通常，分布式事务基于两阶段提交实现，它的工作原理示意图如图2-3所示。图2-3　两阶段提交原理图阶段1：全局事务管理器向所有事务参与者发送准备请求；事务参与者向全局事务管理器回复自己是否准备就绪。阶段2：全局事务管理器接收到所有事务参与者的回复之后做判断，如果所有事务参与者都可以提交，则向所有事务提交者发送提交申请，否则进行回滚。事务参与者根据全局事务管理器的指令进行提交或者回滚操作。分布式事务回滚原理图如图2-4所示。图2-4　分布式事务回滚原理图两阶段提交采用的是悲观锁策略，由于各个事务参与者需要等待响应最慢的参与者，因此性能比较差。第一个问题是协议本身的成本：整个协议过程是需要加锁的，比如锁住数据库的某条记录，且需要持久化大量事务状态相关的操作日志。更为麻烦的是，两阶段锁在出现故障时表现出来的脆弱性，比如两阶段锁的致命缺陷：当协调者出现故障，整个事务需要等到协调者恢复后才能继续执行，如果协调者出现类似磁盘故障等错误，该事务将被永久遗弃。对于分布式服务框架而言，从功能特性上需要支持分布式事务。在实际业务使用过程中，如果能够通过最终一致性解决问题，则不需要做强一致性；如果能够避免分布式事务，则尽量在业务层避免使用分布式事务。2.2　分布式事务优化既然分布式事务有诸多缺点，那么为什么我们还在使用呢？有没有更好的解决方案来改进或者替换呢？如果我们只是针对分布式事务去优化的话，发现其实能改进的空间很小，毕竟瓶颈在分布式事务模型本身。那我们回到问题的根源：为什么我们需要分布式事务？因为我们需要各个资源数据保持一致性，但是对于分布式事务提供的强一致性，所有业务场景真的都需要吗？大多数业务场景都能容忍短暂的不一致，不同的业务对不一致的容忍时间不同。像银行转账业务，中间有几分钟的不一致时间，用户通常都是可以理解和容忍的。在大多数的业务场景中，我们可以使用最终一致性替代传统的强一致性，尽量避免使用分布式事务。在实践中常用的最终一致性方案就是使用带有事务功能的MQ做中间人角色，它的工作原理如下：在做本地事务之前，先向MQ发送一个prepare消息，然后执行本地事务，本地事务提交成功的话，向MQ发送一个commit消息，否则发送一个rollback消息，取消之前的消息。MQ只会在收到commit确认才会将消息投递出去，所以这样的形式可以保证在一切正常的情况下，本地事务和MQ可以达到一致性。但是分布式调用存在很多异常场景，诸如网络超时、VM宕机等。假如系统执行了local_tx()成功之后，还没来得及将commit消息发送给MQ，或者说发送出去由于网络超时等原因，MQ没有收到commit，发生了commit消息丢失，那么MQ就不会把prepare消息投递出去。MQ会根据策略去尝试询问（回调）发消息的系统（checkCommit）进行检查该消息是否应该投递出去或者丢弃，得到系统的确认之后，MQ会做投递还是丢弃，这样就完全保证了MQ和发消息的系统的一致性，从而保证了接收消息系统的一致性。3.研发团队协作问题服务化之后，特别是采用微服务架构以后。研发团队会被拆分成多个服务化小组，例如AWS的TwoPizzaTeam，每个团队由2~3名研发负责服务的开发、测试、部署上线、运维和运营等。随着服务数的膨胀，研发团队的增多，跨团队的协同配合将会成为一个制约研发效率提升的因素。3.1　共用服务注册中心为了方便开发测试，经常会在线下共用一个所有服务共享的服务注册中心，这时，一个正在开发中的服务发布到服务注册中心，可能会导致一些消费者不可用。解决方案：可以让服务提供者开发方，只订阅服务（开发的服务可能依赖其他服务），而不注册正在开发的服务，通过直连测试正在开发的服务。它的工作原理如图3-1所示。图3-1　只订阅，不发布3.2　直连提供者在开发和测试环境下，如果公共的服务注册中心没有搭建，消费者将无法获取服务提供者的地址列表，只能做本地单元测试或使用模拟桩测试。还有一种场景就是在实际测试中，服务提供者往往多实例部署，如果服务提供者存在Bug，就需要做远程断点调试，这会带来两个问题：1）服务提供者多实例部署，远程调试地址无法确定，调试效率低下。2）多个消费者可能共用一套测试联调环境，断点调试过程中可能被其他消费者意外打断。解决策略：绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式将以服务接口为单位，忽略注册中心的提供者列表。3.3　多团队进度协同假如前端Web门户依赖后台A、B、C和D4个服务，分别由4个不同的研发团队负责，门户要求新特性2周内上线。A和B内部需求优先级排序将门户的优先级排的比较高，可以满足交付时间点。但是C和D服务所在团队由于同时需要开发其他优先级更高的服务，因此把优先级排的相对较低，无法满足2周交付。在C和D提供版本之前，门户只能先通过打测试桩的方式完成Mock测试，但是由于并没有真实的测试过C和D服务，因此需求无法按期交付。应用依赖的服务越多，特性交付效率就越低下，交付的速度取决于依赖的最迟交付的那个服务。假如Web门户依赖后台的100个服务，只要1个核心服务没有按期交付，则整个进度就会延迟。解决方案：调用链可以将应用、服务和中间件之间的依赖关系串接并展示出来，基于调用链首入口的交付日期作为输入，利用依赖管理工具，可以自动计算出调用链上各个服务的最迟交付时间点。通过调用链分析和标准化的依赖计算工具，可以避免人为需求排序失误导致的需求延期。3.4　服务降级和Mock测试在实际项目开发中，由于小组之间、个人开发者之间开发节奏不一致，经常会出现消费者等待依赖的服务提供者提供联调版本的情况，相互等待会降低项目的研发进度。解决方案：服务提供者首先将接口定下来并提供给消费者，消费者可以将服务降级同Mock测试结合起来，在Mock测试代码中实现容错降级的业务逻辑（业务放通），这样既完成了Mock测试，又实现了服务降级的业务逻辑开发，一举两得。3.5　协同调试问题在实际项目开发过程中，各研发团队进度不一致很正常。如果消费者坐等服务提供者按时提供版本，往往会造成人力资源浪费，影响项目进度。解决方案：分布式服务框架提供Mock桩管理框架，当周边服务提供者尚未完成开发时，将路由切换到模拟测试模式，自动调用Mock桩；业务集成测试和上线时，则要能够自动切换到真实的服务提供者上，可以结合服务降级功能实现。3.6　接口前向兼容性由于线上的Bug修复、内部重构和需求变更，服务提供者会经常修改内部实现，包括但不限于：接口参数变化、参数字段变化、业务逻辑变化和数据表结构变化。在实际项目中经常会发生服务提供者修改了接口或者数据结构，但是并没有及时知会到所有消费者，导致服务调用失败。解决方案：1）制定并严格执行《服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。2）接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段，字段定义位置无关性，码流支持乱序等。4.总结服务化之后，无论是服务化框架，还是业务服务，都面临诸多挑战，本章摘取了其中一些比较重要的问题，并给出解决方案和最佳实践。对于本章节没有列出的问题，则需要服务框架开发者和使用者在实践中探索，找出一条适合自己产品的服务化最佳实践。

一提三层架构，大家都知道是表现层（UI），业务逻辑层（BLL）和数据访问层（DAL），而且每层如何细分也都有很多的方法。但具体代码怎么 写，到底那些文件算在哪一层，却是模模糊糊的。下面用一个简单的例子来带领大家实战三层架构的项目，这个例子只有一个功能，就是用户的简单管理。

首先建立一个空白解决方案，添加如下项目及文件

1、添加ASP.NET Web Application项目，命名为UI，新建Web Form类型文件User.aspx（含User.aspx.cs）

2、添加ClassLibrary项目，命名为BLL，新建Class类型文件UserBLL.cs

3、添加ClassLibrary项目，命名为DAL，新建Class类型文件UserDAL.cs。添加SQLHelper引用。（这个是微软的数据访 问类，也可以不用，直接编写所有的数据访问代码。我一般用自己写的数据访问类DataAccessHelper ）。

4、添加ClassLibrary项目，命名为Model，新建Class类型文件UserModel.cs

5、添加ClassLibrary项目，命名为IDAL，新建Interface类型文件IUserDAL.cs

6、添加ClassLibrary项目，命名为ClassFactory

相信大家已经看出来了，这个和Petshop的示例没什么区别，而且更简单，因为在下也是通过Petshop学习三层架构的。但一些朋友对于这几个项目所处的层次，以及它们之间的关系，可能比较模糊，这里逐个说明一下：

1、User.aspx和User.aspx.cs

这两个文件（以及文件所属的项目，下面也是如此，不再重复强调了）都属于表现层部分。User.aspx比较好理解，因为它就是显示页面了。 User.aspx.cs有些人觉得不应该算，而是要划到业务逻辑层中去。如果不做分层的话，那么让User.aspx.cs来处理业务逻辑，甚至操作数 据库都没什么问题，但是做分层的话，这样就不应该了。在分层结构中，User.aspx.cs仅应该处理与显示有关的内容，其它部分都不应该涉及。

举例：我们实现用列表方式显示用户的功能，那么提取信息的工作是由BLL来做的，UI（本例中是User.aspx.cs）调用BLL得到 UserInfo后，通过代码绑定到User.aspx的数据控件上，就实现了列表的显示。在此过程中User.aspx.cs对UI没有起到什么作用， 仅是用来传递数据，而且因为实际编码中大部分情况都是如此的实现，所以使有些人觉得User.aspx.cs不应该算UI，而应该并入BLL负责逻辑处 理。继续往下看，这时提出了一个新需求，要求在每个用户的前面加一个图标，生动地表现出用户的性别，而且不满18岁的用儿童图标表示。这个需求的实现，就 轮到User.aspx.cs来做了，这种情况下User.aspx.cs才算有了真正的用途。

2、NewBLL.cs

添加如下方法：

public IList GetUsers()：返回所有的用户信息列表

public UserInfo GetUser(int UserId)：返回指定用户的详细信息

public bool AddUser(UserInfo User)：新增用户信息

public bool ChangeUser(UserInfo User)：更新用户信息

public void RemoveUser(int UserId)：移除用户信息

此文件就属于业务逻辑层了，专门用来处理与业务逻辑有关的操作。可能有很多人觉得这一层唯一的用途，就是把表现层传过来的数据转发给数据层。这种情况确实 很多，但这只能说明项目比较简单，或者项目本身与业务的关系结合的不紧密（比如当前比较流行的MIS），所以造成业务层无事可做，只起到了一个转发的作 用。但这不代表业务层可有可无，随着项目的增大，或者业务关系比较多，业务层就会体现出它的作用来了。

此处最可能造成错误的，就是把数据操作代码划在了业务逻辑层，而把数据库作为了数据访问层。

举例：有些朋友感觉BLL层意义不大，只是将DAL的数据提上来就转发给了UI，而未作任何处理。看一下这个例子

BLL层

SelectUser（UserInfo userInfo）根据传入的username或email得到用户详细信息。

IsExist（UserInfo userInfo）判断指定的username或email是否存在。

然后DAL也相应提供方法共BLL调用

SelectUser（UserInfo userInfo）

IsExist（UserInfo userInfo）

这样BLL确实只起到了一个传递的作用。

但如果这样做：

BLL.IsExist（Userinfo userinfo）

{

UerInfo user = DAL.SelectUser（User）；

return (userInfo.Id != null)

}

那么DAL就无需实现IsExist()方法了，BLL中也就有了逻辑处理的代码。

3、UserModel.cs

实体类，这个东西，大家可能觉得不好分层。包括我以前在内，是这样理解的：如此则认为Model在各层之间起到了一个数据传输的桥梁作用。不过在这里，我们不是把事情想简单，而是想复杂了。

Model是什么？它什么也不是！它在三层架构中是可有可无的。它其实就是面向对象编程中最基本的东西：类。一个桌子是一个类，一条新闻也是一个类，int、string、doublie等也是类，它仅仅是一个类而已。

这样，Model在三层架构中的位置，和int，string等变量的地位就一样了，没有其它的目的，仅用于数据的存储而已，只不过它存储的是复杂的数据。所以如果你的项目中对象都非常简单，那么不用Model而直接传递多个参数也能做成三层架构。

那为什么还要有Model呢，它的好处是什么呢。下面是思考一个问题时想到的，插在这里：

Model在各层参数传递时到底能起到做大的作用？

在各层间传递参数时，可以这样：

AddUser（userId，userName，userPassword，…，）

也可以这样：

AddUser（userInfo）

这两种方法那个好呢。一目了然，肯定是第二种要好很多。

什么时候用普通变量类型（int,string,guid,double）在各层之间传递参数，什么使用Model传递？下面几个方法：

SelectUser（int UserId）

SelectUserByName（string username）

SelectUserByName（string username，string password）

SelectUserByEmail（string email）

SelectUserByEmail（string email，string password）

可以概括为：

SelectUser（userId）

SelectUser（user）

这里用user这个Model对象囊括了username，password，email这三个参数的四种组合模式。UserId其实也可以合并到user中，但项目中其它BLL都实现了带有id参数的接口，所以这里也保留这一项。

传入了userInfo，那如何处理呢，这个就需要按照先后的顺序了，有具体代码决定。

这里按这个顺序处理

首先看是否同时具有username和password，然后看是否同时具有email和password，然后看是否有username，然后看是否有email。依次处理。

这样，如果以后增加一个新内容，会员卡（number），则无需更改接口，只要在DAL的代码中增加对number的支持就行，然后前台增加会员卡一项内容的表现与处理即可。

4、UserDAL.cs

public IList SelectUsers()：返回所有的用户信息列表

public UserInfo SelectUser(int UserId)：返回指定用户的相信信息

public bool InsertUser(UserInfo User)：新增用户信息

public bool UpdateUser(UserInfo User)：更新用户信息

public void DeleteUser(int UserId)：移除用户信息

很多人最闹不清的就是数据访问层，到底那部分才算数据访问层呢？有些认为数据库就是数据访问层，这是对定义没有搞清楚，DAL是数据访问层而不是数据存储 层，因此数据库不可能是这一层的。也有的把SQLHelper（或其同类作用的组件）作为数据访问层，它又是一个可有可无的东西，SQLHelper的作 用是减少重复性编码，提高编码效率，因此如果我习惯在乎效率或使用一个非数据库的数据源时，可以丢弃SQLHelper，一个可以随意弃置的部分，又怎么 能成为三层架构中的一层呢。

可以这样定义：与数据源操作有关的代码，就应该放在数据访问层中，属于数据访问层

5、IUserDAL

数据访问层接口，这又是一个可有可无的东西，因为Petshop中带了它和ClassFactory类工厂，所以有些项目不论需不需要支持多数据源，都把 这两个东西做了进来，有的甚至不建ClassFactory而只建了IDAL，然后“IUserDAL iUserDal = new UserDAL()”，不知意义何在。这就完全是画虎不成反类犬了。

许多人在这里有一个误解，那就是以为存在这样的关系：认为IDAL起到了BLL和DAL之间的桥梁作用，BLL是通过 IDAL来调用DAL的。但实际是即使你如此编码：“IUserDAL iUserDal = ClassFacotry.CreateUserDAL()；”，那么在执行“iUserDal.SelectUsers()”时，其实还是执行的 UserDAL实例，而不是IUserDAL实例，所以IDAL在三层中的位置是与DAL平级的关系。

通过上面的介绍，基本上将三层架构的层次结构说明了。其实，本人有一个判断三层架构是否标准的方法，那就是将三层中的任意一层完全替换，都不会对其它两层 造成影响，这样的构造基本就符合三层标准了（虽然实现起来比较难^_^）。例如如果将项目从B/S改为C/S（或相反），那么除了UI以外，BLL与 DAL都不用改动；或者将SQLServer改为Oracle，只需替换SQLServerDAL到OracleDAL，无需其它操作等等。本来想在文中 加入一些具体的代码的，但感觉不是很必要，如果大家觉得需要的话，我再补充吧。

总结：不要因为某个层对你来说没用，或者实现起来特别简单，就认为它没有必要，或者摒弃它，或者挪作它用。只要进行了分层，不管是几层，每一层都要有明确 的目的和功能实现，而不要被实际过程所左右，造成同一类文件位于不同层的情况发生。也不要出现同一层实现了不同的功能的情况发生。