Asp.Net开发架构设计
转：http://www.cnblogs.com/xiaozhuang/archive/2008/08/15/1268907.html
这几天园子里关于软件架构的讨论还是相当激烈，大家都想要一种能最大限度的降低各层之间依赖关系的的架构来适应变化的需求，谁都不喜欢改一点而动全身，尽量降低各层的改动产生的相互影响。
本篇我以理论和实践（源代码）两个方面和大家探讨一下我的方案，希望大家多提宝贵意见。
一、软件架构的概念问题，什么是软件的架构?我的理解是：软件的架构包括两个方面的内容，一个是软件的开发架构，一个是软件的部署架构，所谓部署架构就是指部署时的分布式，集群等设计问题；开发架构就是我们平常说的软件分层设计问题，也就是我们今天要谈的问题。
二、何谓分层？分层的方式有几种？分层也就是把一个大的软件解决方案分成多个项目进行开发，分为三种，一种是按照代码的功能层次进行分层，分为数据库访问层，业务逻辑层，UI层等，一种是按照要实现的功能模块进行分层，例如新闻管理层，博客管理层等，第三种就是把前两者结合起来进行分层：先按照代码功能划分好层次，然后再在每一层中分层成各个功能模块。
三、面向接口能够降低各层之间的依赖关系吗？还需要什么？面向接口只是把对对象的直接调用转到了对接口的调用身上，但对接口的调用也需要对象的实例化为前提，因为有对象实例化的存在，所以接口并不能屏蔽掉背后的对象来完成功能；在这种情况下，依赖注入/控制反转等概念应运而生，IOC容器出现了，它能够让对象自动实例化，并管理对象的生存空间。
四、说了这么多，到底应该怎样分？我们不妨从软件的开发过程上来考虑，做软件的都知道我们要进行需求分析，要有需求分析文档，需求分析的任务就是把客户的需求转变为对软件功能的需求，主要内容包括：软件要实现那些功能模块，每个功能模块下包含哪些业务操作，这些业务操作需要哪些页面（或者窗口）支持，这些页面大概都是什么样子的，上面都有什么？有了这些信息，我们就可以开始我们的系统设计了。
我的方案中各个项目的引用关系如下：
说明：
Web：UI层，Asp.net Web应用程序项目，提供用户界面。
UnityConfig：依赖注入配置层，类库项目，对Service层和Business层进行实现配置以提供给Web调用Service层。
Service：为Web层提供服务，类库项目，里面全是接口。
Business：商业逻辑层，通过调用DA数据访问层和Entities层来实现Service层的服务接口。类库项目。
Entities：实体层，
相关文档：
随 着网站访问量的加大，每次从数据库读取都是以效率作为代价的，很多用ACCESS作数据库的更会深有体会，静态页加在搜索时，也会被优先考虑。互联网上流 行的做法是将数据源代码写入数据库再从数据库读取生成静态面，这样无形间就加大了数据库。将现有的ASP页直接生成静态页，将会节省很多。
下面的例子是将、index.asp?i ......
string path = "...\\Debug\\log.txt";
if (!File.Exists(path))
& ......
ASP.NET三层结构说明
完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层。否则你的应用是不是多层结构,或者说是层结构的划分和组织上是不是有问题就很难说.不同的应用有不同的理解，这只是一个概念的问题．
理解ASP.NET三层结构——为什么要分三层？
我们用三层结构主要是使� ......
1. 打开新的窗口并传送参数：
传送参数：
response.write("<script>window.open('*.aspx?id="+this.DropDownList1.SelectIndex+"&id1="+...+"')</script>")
接收参数：
string a = Request.QueryString("id");
string b = Request.QueryString("id1");
2.为按钮添加对话框
Button1.Attribut ......
为什么要状态管理
B/S与C/S两种架构的有着完全不同的运行机制。C/S基本上所有的软件功能都在客户端(Client)中实现（所以C/S也称为胖客户端架构），服务器端(Server)只提供基础服务，最为典型的是数据库服务提供数据服务。而B/S架构主要的功能在服务端(Server)实现，客户端的浏览器( ......
