架构网站有1多点的时间了吧。但是什么架构才是真正的好的架构的架构呢？不得而知。
真正的运用于每个系统，作用于每个系统得东西才是好的吧。三层，一个很通用的架构，其优点，便于网站维护和后续开发。说实话，感觉还是有些不敢苟同。便于网站维护，如果说到网站维护我把DAL层和BLL（数据访问层和业务逻辑层）结合成一层也没有什么吧。即使涉及后续开发，也只是简化了。并没有加重呀。当然，接口还是有一定必要。不是为了好维护，而是为了在进行网站结构的时候能指导程序员进行网站程序的具体实现（其实这一点，很多时候都不会遇见。只有当遇见一个真正大的网站的时候你才会真正的遇见）。下面我简单的说下三成架构。
DBUtility 数据基层
IDBUtility 数据基层接口
IDAL 数据层接口
DAL 数据层
DALFactory 数据层工厂
BLL 业务逻辑层
Model 实体层
GUI 界面表示层
DBUtility
其主要用于在于对数据操作的封装。在我的这一层里面。他主要有
SqlDBUtility 操作Sql数据库的 继承于IDBUtility
AccessDBUtility 操作Access数据库 继承于IDBUtility
OracleDBUtility 操作Oracle数据库 继承于IDBUtility
MysqlDBUtility 操作Mysql数据库 继承于IDBUtility
IDBUtility
其作用，主要是为了定义相关的实现方法。如果只是一个规模小的网站。或者说以后对其他数据库不会扩展的我觉得没有必要使用这一层。而且这一层也可以完全可以和DBUtility和在一起。如果可以，在里面加上工厂也是可以的。他会直接把方法创建在内存里面，从而减少了消耗。
其主要包括
执行存储过程方法的封装
执行SQL语句的方法的封装。
执行事物
IDAL
其作用主要是定义数据层相关一些方法的实现。
其主要类随着数据的变化而变化。但是，他首先会包括一些基础操作。对数据的增 删 改 查。当然，肯定还会进行扩展。例如查询也分很多种时候。还有就是查询还会有相应的关联。
DAL
当然是对接口的实现了。这里主要包括对数据访问层的SQL的封装和参数，执行存储过程的名称调用。组合具体的SQL语句和存储过程参数。以及调用得存储过程的名称。
DALFactory
利用接口创建他的实现方法。存放于内存里面。方便以后进行调用。同时减少层代码之间的耦合度。
BLL
这里是对要调用的DAL实现数据的组合。和业务逻辑的实现。其实我一直质疑。其存在的意思。这一层完全可以和DAL层组合起来。也有的时候觉得，一用起来也有点方便。当你需要操作多个表的时候，在这里你可以掉DAL层的相关代码进行组合就可以了。不用在DAL那些地方浪费很多的没有用的代码。不过有了这一层。也同样的浪费了很多代码。在实际工作中。很多时候，这里就只有哪么几句return dal.Add(model);很浪费人的表情。你说是不是。Model层还是GUI这一层进行的组合。所以很是让人郁闷呢。
Model
实体层，其主要包括对应的相关的数据实体的封装。我们都知道，SQL等数据库都是关系型数据库，而C#等语言都遵循的是面对对象。但是拥有了Model层以后，会让我们感觉我们操作的不是数据库。而是相关实体。通过对实体的操作完成对数据库的操作。当然这一层还包括更多的东西。例如在数据分析的时候，我们分析员工 我们通常会把员工所有信息放在一起。例如基础信息（姓名 身份证号 性别 所在部门 登陆系统密码）他里面就包括两种信息。一种就是基础不动的信息。一种是经常更变的信息。为了尽可能的减少负担。我们会把两种信息分存储。这些在进行修改的时候也方便。同时更加的减少和服务器交互的数据量。不过加重了查询时候的数据量。所以如果数据量相对很是庞大的时候，我建议还是不要分开。因为数据库在进行匹配的时候是相当耗费计算机内存的。说多了，说到数据分析上面去了。我的意思就是你可能需要在这里进行两个表的实体整合到一起。这样你在操作起来的时候也会方便一些。同时在这里，你还需要相应的数据的一些验证。例如长度，类型，数据本身的合法性。
GUI
这里是页面层。其实这一层不用多说的。他就包括获取提交数据，验证提交数据，页面数据绑定。然后就把数据提交到BLL层。
其实除了这些层。很可能还包含一些。例如Common公共层。其中包括，一些弹出提示的JS的封装。还有Split字符串的一些自定义方法的封装。同时还可能包含一个MyControls这样的一层，其中包括自己的一些控件的封装了。例如时间控件。分页控件。
好了。三层就简单的介绍到这里。希望大家可以给我一些建议，对这篇文章的建议。让我及时的更正。