在正式动手开发网站之前，首先应当对将要开发的网站进行认真规划和设计，弄清楚自己想要的网站是个什么样子，这很重要。一般来讲，网站规划设计包括网站功能、物理部署、期望性能、架构分层等几个方面。

3.1　功能规划

网站要实现的功能视商业目的、用户需求而定，在正式开始开发之前一定先要规划好网站的功能，只有在事先规划好功能，才能够在开发中少走弯路，快速地将网站交付。

首先，根据功能需求确定采用B/S网站开发的架构是否合适。现在有很多公司和客户盲目追赶所谓的"B/S"大潮，认为一切应用都可以且应该使用B/S架构来实现，实际上这是极不明智的行为。

一般来讲，只有在如下情况下才有使用B/S的必要：

（1）系统安全性要求不是非常高，从某种意义上来讲是公开的。换句话说就是这个应用是可以让大家都知道的，包括系统的和非合法用户。但是如果不是这样，那么就不要使用B/S架构，比如企业内部使用的进销存管理系统。

（2）目标用户群体是开放的或公开的，并不限定于少数已知且确定的人群。

（3）不需要离线使用的应用程序。

在确定使用网站的方式来呈现系统之后，我们需要对系统功能进行进一步的分析，一般要考虑如下几点：

（1）功能的单一性和关联性。简单地说就是“高内聚，低耦合”，一个网站所实现的功能尽量单一或者多个功能之间具有关联性，否则请考虑开发成多个网站。

（2）用户的单一性。网站的用户群体也应当尽量单一。

（3）后台管理的开放性。一般来讲这里要考虑的是网站的后台管理部分是否也使用B/S架构来开发，比如一个典型的电子商务网站，那么后台的订单管理、配送管理等功能是不适合使用B/S架构的。

3.2　部署规划

在设计完功能，充分了解需求之后，就应当考虑系统将来的部署问题，这个时候应当对目标用户群做一个调查，了解用户的使用情况，比如一般都多少人同时在线，通常采用什么方式上网，哪些功能用得比较多，等等。然后根据这些调查数据进行部署规划。

1.部署到局域网还是因特网　是部署到局域网还是因特网主要看使用人群以及使用地点，如果使用人群主要是企业内部员工，并且一般不会在家或者出差时登录，则部署到局域网中会比较合适，相对来说安全得多，如果在某些情况下需要从外部访问，可以考虑使用VPN。

2.如何解决网间互连问题　不知道这个问题算不算是中国特色。因为电信和网通间的互联互通并不通畅，如果我们的系统部署在因特网上，那么就需要认真考虑如何解决这个问题，否则将来它可能会是个大麻烦。

解决办法一般有3种：

（1）使用两台服务器，分别部署在电信和网通的机房里，然后电信和网通的用户分别访问各自的服务器，这种方法是最基本的解决方案，但是两台服务器间的数据同步将会是一件让人比较头疼的事情。

（2）使用一台服务器，部署在电信或者网通某个服务商的机房里，然后找一家镜像站点公司，这样的镜像站点公司会有很多的服务器，分布在全国各地，和他们签约后，他们的镜像服务器会定时到你的服务器上抓取静态页面并储存起来，这样各地的用户访问你的网站的时候，实际上是访问在他们本地的镜像服务器的内容，这种方式对于访问速度的改善最为明显，因为已经不仅仅解决了网间互联的问题，实际上每个用户访问的都是本地的（比如说是本市或本省的）服务器。但这种方案的缺陷是它只比较适合于主要是静态内容的网站，对于我们使用ASP.NET技术构建的动态站点来说并不合适。

（3）使用一台服务器，装上两块网卡，找一个同时有电信和网通两个出口的主机托管服务商，两块网卡分别接到电信和网通两个出口上，然后电信和网通的用户分别通过各自的出口访问同一台服务器。这是相对来说比较完美的解决方案，只是需要找这样一家能够同时提供两个不同的网络出口的主机托管服务商不是一件很容易的事情。青岛网站建设视觉导向性

3.3　性能规划

在性能方面的规划也要在前面所做的对用户进行的访问调查的基础上进行，根据用户数及并发访问量等数据来进行考虑。

3.3.1　升级服务器还是采用多服务器

在需要提高网站性能的时候，一般有两种方案可以考虑，一种是升级服务器，另外一种是采用多服务器部署。

升级服务器，换用更高频率或者多核CPU、增加内存，可以提高单服务器性能，加快相应速度，但毕竟可升级的空间是有限的，尽管能够缩短一些页面响应时间，但是并不能够很好地应对访问请求量增大的情况。

采用多服务器部署，将网站从单纯的逻辑分层变为物理分层，比如将数据库、业务逻辑和Web站点分别部署到单独的服务器上，甚至进一步将每一层应用

都分别平行分布到多台服务器上。采用这种方式可以有效应对访问量增大的情况，但是由于产生了服务器间的通信数据量，对于单个请求来讲，响应时间不会得到缩短，反而还有可能延长。而且采用多服务器部署的方式，对系统的开发也会产生影响，如果系统分层的层间通信是采用紧耦合的方式，那么就无法分布到多台服务器上，然后在多服务器部署的情况下还要考虑Session的储存，以及服务器间采用何种方式通信等问题。

3.3.2　多服务器间通信的性能考虑

如果确定采用多服务器的部署模式，那么就要认真考虑多服务器间通信所存在的性能问题及其解决办法。

首先，参与分布式计算的成员服务器之间最好采用高速局域网连接，如果因服务器分布于不同地点而无法放置于同一局域网内，那么也应当使用高速专线相连，这不仅是基于性能的考虑，同时也是基于安全的考虑。

其次，服务器间数据传输应当遵守“低频率、粗粒度”的原则，服务器间连接的次数应当尽量低，每次连接传输的数据应当尽量多一些。因为服务器间数据传输的速率毕竟始终无法与访问内存或硬盘的速率相比，而且建立连接、管理连接也是需要消耗时间成本的，所以相比从其他服务器获取数据，更应当优先考虑从本地内存或硬盘中读取数据，而如果将总的连接时间（包括建立连接、传输数据、关闭连接）视为分母，传输有效数据的时间视为分子，那么很显然这个比值应当尽可能地接近于1才是比较理想的。当然，传输的总数据量也不能太大，必须使总的连接时

间保持在可接受的范围内。

再次，应当考虑服务器间的连接技术。例如，使用Web Services和.NET Remoting连接，其性能是大不一样的。如果相互连接的两台服务器是采用的不同技术开发的，那么使用Web Services互联是比较好的连接方式，但是效率较低；如果相互连接的两台服务器都是采用.NET技术开发的，那么近期推荐采用.NET Remoting互联，远期则推荐使用Windows Communication Foundation互联，这样效率比较高，而且开发简便、功能强大。

最后，必须考虑建立服务器缓存。对于多服务器连接的系统，在某些服务器上建立数据缓存是必要的，这样可以有效地减少服务器建立数据连接的次数，从而提高响应速度。但是在哪些服务器上建立缓存，建立什么样的缓存，则是需要仔细考虑的。以典型的数据库服务器、业务处理服务器、网站服务器的三服务器应用模式为例，业务处理服务器上应当建立数据缓存，对数据库中的常用数据进行缓存；而在网站服务器上，则只适合建立对于静态页面的页面缓存。

3.4　网站架构分层设计

对网站系统进行分层是必要的，这不仅仅是因为需要对网站进行物理分层，即部署到多台服务器上，还因为：

（1）充分发挥开发人员特长。因为人无完人，并不是每个人都是全能选手，有些人只精通C#，有些人却只喜欢T-SQL，还有专业美工人员，等等，如果将

不同类型代码混杂在一起进行开发，将无法发挥每个工作人员的特长。

（2）增强代码可读性。其实这一点和上一点相类似，只不过关注点从写变成了读。同时还因为将功能区隔开来，每个文件只关心一个功能点，这样进一步提高了源码的可读性。

（3）实现代码重用。很明显网站系统中有很多可以重用的模块，比如数据访问、数据缓存、身份认证以及权限控制，这些模块都可以也应当提取出来进行重用，从而大量减轻工作量和缩短开发时间。

（4）易于扩展。网站系统在使用过程中可能会根据需要进行扩展，例如增加或修改功能，部署到更多的服务器上等，那么在设计开发的时候就需要考虑到这种情况，分层开发也是为了应对这种情况的出现。在定义好接口之后，当系统进行扩展时，只要新开发的模块符合接口规范，那么原有代码只需要进行很小的修改甚至不需要修改，就可以方便地加入新的模块或替换掉旧的模块。

（5）易于分布式部署。逻辑分层是物理分层的前提，只有进行了逻辑分层，并考虑了层与层之间的服务器传输，才能将其分布到多台服务器上。3.4.1　系统分层图

网站系统分成多少层，分为哪些层，并没有一个统一的定论，根据经验和需要，每个系统架构师都会有不同的理解。笔者根据自己近年来做.NET B/S系统开发和架构的经验，以系统能够方便地分布到三台服务器上，并且能够方便地进一步扩

展为目标。

3.4.2　数据定义层

数据定义层将为从数据访问层到界面层的所有层次使用，这一层用于定义数据结构，比如强类型数据集，或纯粹描述数据的类、结构以及枚举。

基于数据与行为分离的原则，这一层只包含对数据结构的定义，而不包含对数据的操作。

3.4.3　数据访问层

数据访问层执行从数据库（或其他数据服务）获取数据或向数据库发送数据的功能。在分布式应用程序结构中，相应功能使用ADO.NET数据适配器和SQL服务器存储过程来完成：

（1）从“业务规则”层接收请求，从“数据服务”获取数据或向其发送数据。

（2）使用存储过程获取数据，并可选用ADO.NET向数据库发送数据。

（3）以强类型的ADO.NET数据集的方式，将数据库查询结果返回到“业务规则”层。

数据访问层如果设计得足够合理，将具有高度的灵活性：高度可复用、高度可扩展，并且在数据源类型改变时无需修改程序。在第5章中我们将进行详细阐述。

3.4.4　数据缓存层

数据缓存层的存在旨在减少对数据库的访问次数，以提高性能。数据对于大多

数系统来说是核心，大部分的操作都是对数据的访问操作，包括查询、读取和新增修改删除。每一次对数据库的查询都是宝贵的，不能只使用一次就马上丢弃。尤其在遵循“低频度、粗粒度”的服务器间连接原则的系统上，每一次对数据库的访问都读取了大量的数据，但这大量的数据在页面上显示的时候，可能只显示了其中很小的一部分，如果在显示了这小小的一部分之后就马上丢弃的话，粗粒度原则也就没有任何意义了。所以需要在每次查询数据库之后，将查询结果缓存起来，留待下次使用。

那么随之带来的问题就是：服务器的内存大小毕竟是有限的，在数据被缓存之后，总要在合适的时候释放，怎样设计这样的一套释放机制才是合理的；当对数据库进行新增、修改、删除操作之后，数据缓存中的数据和数据库中的数据需要进行同步，才能保证显示数据和实际数据一致，该怎样进行同步才能够保证其可靠性；更为复杂的是，如果在部署中存在多台业务逻辑服务器，而每台业务逻辑服务器都配置了数据缓存，那么该通过怎样的一个机制来保证多台服务器中的数据都是一致的。关于这些问题，我们将在第6章进行描述。

另外，为了保证数据访问的灵活性，最好能够使数据访问层和数据缓存层实现相同的接口。

3.4.5　业务逻辑层

业务逻辑层包含业务对象本身以及应用于它们的规则。这也是主要业务对象所在的位置。它们实现业务实体或系统对象。系统的业务规则将在这些对象中编

码，尽管部分业务规则可能实际上已在数据库的存储过程和触发器中进行了编码。

业务逻辑层的作用是：

·从“业务界面”层接受请求。

·根据编码的业务规则处理请求。

·使用“数据访问”层从“数据服务”层获取数据，或将数据发送到“数据服务”层。

·将处理结果传递回“业务界面”层。

3.4.6　业务界面层

业务界面层常用于向基础业务对象提供一致的接口，并将客户端同基础业务逻辑的更改隔离开。当它出现时，其或者处于客户端和业务逻辑之间，或者处于Web服务层和业务逻辑层之间。

在本系统架构中，业务界面层分为两层，用于跨服务器的数据传输，这样设计的目的是，在根据需要改变数据传输方式时，在保证接口不变的前提下，只需要对这两层进行替换即可，而不需要修改业务逻辑层或界面层的代码。

业务界面层的作用是：

·从“界面”层（Web用户界面客户端应用程序）接收用户输入。

·如果请求需要对数据进行只读访问，则可能使用“数据访问”层。

·将请求传递到“业务规则”层。

·将响应从“业务规则”层返回到“界面”层（Web用户界面客户端应用程序）。

在技术上，根据需要的不同，目前推荐使用.NET Remoting或Web Services：如果考虑需要与采用其他技术的系统进行数据交换，比如采用JSP技术的青岛网站制作或其他公司采用Java等其他技术开发的系统，则推荐使用Web Services，这样保证了比较好的兼容性，只是效率相对较低；如果只是与同样采用.NET技术的系统相连接，那么推荐使用.NET Remoting，这样效率较高。而远期则推荐使用Windows Communication Foundation技术。

同时，为了保证代码调用的灵活性，业务界面层Client和业务逻辑层最好能够实现相同的接口。

3.4.7　界面层

界面层是指在应用程序中实现的客户端。在分布式应用程序结构中，用户服务可以是Web客户端或Windows客户端，或者两者都是，或者两者都不是，这具体

取决于特定的应用程序。这里，特定于Web客户端。

界面层起的作用是：

·管理Web页的呈现和行为。

·显示数据。

·捕获数据。

·数据验证检查。

·为用户提供任务指南。

·向“业务外观”发送用户输入。

·从“业务外观”接收结果。

·向用户显示错误。

对于Web界面层的开发技术将是本书的重点，我们将在后面进行详细论述。