㈠ c#利用三层架构写分页查询价的简单实例
首先还是简单的提一下 三层架构吧：
1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是誉卖对数据层的操作，对数据业务逻辑处理。
3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
下面就介绍一下 范例的 步骤：
1.打开VS2008后，文件-->新建-->项目-->其他项目类型-->Visual Studio 解决方案-->空白解决方案 就起名为:MvcTest 吧
2.建立
的项目,并在WEB-->App_Data建一个数据文件 DabaBase.mdf 里面建表:qzzm_user 表内:字段Name,类型:nvarchar(50) 非空
3.在WEB中引用BLL,Model层新建Post.aspx
Post.aspx 代码如下：睁册
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Post.aspx.cs" Inherits="Post" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>无标题页</title>
</head>
<body>
<form id="form1" runat="server">
<div>庆早逗
<asp:TextBox ID="tb_name" runat="server"></asp:TextBox>
<asp:Button ID="btn_post" runat="server" OnClick="btn_post_Click" Text="提交" />
</div>
</form>
</body>
</html>
Post.aspx.cs 先搁下等写好类库再写
4.在Model 实体类中新建一个user.cs的类 （如果你已经按照上面的图 将类都建好了 就只用看下面的代码就好了）
user.cs代码如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Model
{
public class user
{
public user() { }
private string _Name;
public string Name
{
set { _Name = value; }
get { return _Name; }
}
}
}
5.在DAL新建userdb.cs,并引用Model层 （鼠标右键——添加引用——项目 选择所需的引用）
userdb.cs代码如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.sqlClient;
using System.Configuration;
namespace DAL
{
public class userdb
{
public bool adser(Model.user model)
{
SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["sqlconn"].ConnectionString);//此行@
con.Open();
using (SqlCommand cmd = new SqlCommand("INSERT INTO qzzm_user(Name) VALUES(@Name)", con))
{
cmd.Parameters.AddWithValue("@Name", model.Name);
if (cmd.ExecuteNonQuery() > 0)
return true;
else return false;
}
}
}
}
代码写好了还不行，因为到时候调试的时候可能会出现 “当前上下文中不存在名称“ConfigurationManager” ”（注释 所在行），出现这种错误的原因是没有引用System.Configuration 这项，注意这边可不是代码中的 using System.Configuration; 哦。此时就要添加System.Configuration的引用，方法同上面的引用Model层类似，在DAL层下 右键——添加引用——.NET 然后找到对应的 System.Configuration 确定即可。
（如果没出现上面所说的问题当然是最好咯 O(∩_∩)O~）
6.在BLL中新建userbll.cs并引用DAL,Model层
userbll.cs代码如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace BLL
{
public class userbll
{
DAL.userdb db = new DAL.userdb();
public bool adser(Model .user model)
{
return db.adser(model);
}
}
}
7.开始写Post.aspx.cs
代码如下：
using System;
using System.Collections;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
public partial class Post : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void btn_post_Click(object sender, EventArgs e)
{
Model.user us = new Model.user();
us.Name = tb_name.Text;
BLL.userbll ub = new BLL.userbll();
ub.adser(us );
}
}
8.在Web.config文件中添加 缺少的数据链接字符串
找到<connectionStrings /> 这一行，将其修改如下：
<connectionStrings>
<add name="sqlconn" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\Database.mdf;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />
</connectionStrings>
9. 调试 执行
此时会提示 “无法直接启动带有……”的信息
此时我们只要找到 Post.aspx 右键——在浏览器中查看 即可 。 输入数据——提交 ，即可到所建的数据库中找到所输入的数据。
一个简单的三层架构例子 到此完成。
各层引用关系如下：
1) WEB引用 DAL,Model
2)BLL引用 DAL,Model
3)DAL引用Model （以及解决错误时 引用的System.Configuration ）
4)Model无引用
㈡ 在Javaweb中如何体现三层架构思想
一个非常好的问题。三层或者多层架构的核心思想是分层，不同粒度和维度都有应用。
一，系统架构
常见的动静分离、数据中台、微服务在一定程度上都是将系统实现进行分层解耦，从而使顷游空得系统表现为不同的层次，比如典型的前端页面展示、接口服务、数据存储。
二，前端架构
以典型的AntDesign开发信息管理系统为例，将前端实现分为Page、Model、Service三层，Page展示页面响应用户操作，Model保雀瞎存数据，Service处理业务逻辑、调用后台服务接口。
三，后磨坦端架构
在后端开发中，仍然会采用分层架构。比如常用的Java+SpringBoot框架开发Web服务时，有Controller，Service，Entity，分别封装
我是工作多年的Web应用架构师，欢迎在线咨询
㈢ 昌平电脑培训分享三层架构实现JavaWeb案例
三层架构一方面是为了解决应用程序中代码之间调用复杂，代码职责不清的问题;通过各层之间定义接口的形式，并将接口与实现分离，可以很容易的用不同的实现来替换原有的实现，从而有效的降低层与层之间的依赖关系。这种方式不仅有利于整个团队理解整个应用架构，降低后期维护成本，同时也有利于制定整个应用程序架构的标准。
另一方面三层架构的出现从某种程度上解决了企业内部如果有效的根据技能调配技术人员，提高生产效率的问题，在大环境下，有效的分层能使不同职责的人各司其职，聚焦于个人专业技能的发展与培养上。
三层架构的出现不仅标准化了复杂系统的逻辑划分，更帮助企业解决如果有效的形成技术人员组织机构的问题，因此在很长的一段时间内，它一直是软件架构设计的经典模式之一。
优势
层次清晰，每个层次都提供了接口定义
很容易用新的实现替换原来的层次实现。例如对sql进行性能优化，并不会影响其他层的代码结构。有利于后期维护。
有利于实现切面编程，减轻业务的复杂程度，加快编码效率。
每个层正滑悔次的定位明晰，业务处理的内容明确。依据层次，可以划分不同的分工。开发人员可以只关注整个结构的其中某一层。
接口定义也提供了良好让闷的可扩展性。例如数据库从mysql切换到oracle，只需要通过配置来切换。
降低了代码之间，层与层的依赖关系
复用性：利于各层代码逻辑的复用
安全性：接口设计需要符合对扩展开发，对修改关闭的原则，增强了系统的安全性
各层次职责
表示层：是应用的用户接口部分，担负着用户与应用的对话，交互功能。
业务逻辑层：主要是业务逻辑的处理，操作，是系统功能核心。
数据访问层：也称为是数据持久层，昌平电脑培训发现其功能主要是负责数举正据库的访问。
㈣ Java Web 开发时的 MVC 模型和软件的3层架构(表现层，业务逻辑层，数据访问层)有哪些区别和联系
三层架构和MVC是有明显区别的,MVC应该是展现模式(三个加起来以后才是三层架构中的UI层)
三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的UI层，也就是说，MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。
㈤ 什么是jsp web三层架构
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层（又称为持久层）、业务逻辑层（又或称为领域层）、表示层。
表示层（UI层）:
表示层也称为界面层，位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。
业务逻辑层（BLL层）:
负责关键业务的处理和数据的传递。复杂的逻辑判断和涉及到数据库的数据验证都需要在此做出处理。主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
数据访问层（DAL层）：
主要负责对数据库的直接访问，为业务逻辑层提供数据，根据传入的值来操作数据库，增、删、改、查。
㈥ 什么是三层架构各层的主要功能及相互关系有哪些
一般讲到三层架构，其实就是将整个业务应用划分为表示层、业务逻辑层、数据访问层等。
数据访问层DAL，业务逻辑层BLL。表现层UI （界面类的）【 model（数据模型层，主要放的我就不用说了。一般都是数据库中的。） ，】model是贯穿的。所有的都引用它，bll引用dal ui引用dal 和bll 然后就是调用
三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
普通三层：数据访问层DAL：用于实现与数据库的交互和访问，从数据库获取数据或保存数据到数据库的部分。 业务逻辑层BLL：业务逻辑层承上启下，用于对上下交互的数据进行逻辑处理，实现业务目标。 表示层UI：主要实现和用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层去处理。业务实体Model：用于封装实体类数据结构，一般用于映射数据库的数据表或视图，用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦，为了更好地发挥分层的作用，更好地进行复用和扩展，增强灵活性。 通用类库Common：通用的辅助工具类
工程模式：简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。
工厂角色（Creator）
是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。
抽象产品角色（Proct）
是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。
具体产品角色（Concrete Proct）
继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。
通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通 讯与中间层建立连接，再经由中间层与数据库进行交换.
完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层 否则你的应用是不是多层结构,或者说是层结构的划分和组织上是不是有问题就很难说. 不同的应用有不同的理解，这是一个概念的问题．
MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。
MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。 同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。 在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
在ASP NET中的MVC架构编写的，具有极其良好的可扩展性。它可以轻松实现以下功能： ①实现一个模型的多个视图；②采用多个控制器；③当模型改变时，所有视图将自动刷新；④所有的控制器将相互独立工作。这就是MVC架构的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC架构实现的应用程序具有极其良好的可扩展性，是ASP NET面向对象编程的未来方向。
MVC的不足体现在以下几个方面：（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。（4）目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
三层架构是将代码按其作用分成三部分,每部分解决自己负责的流程. 三层架构的功用之处,在于驾驭大型web程序的结构,使之便于管理和扩展.
在设计UI的时候,我们不需要关心其中的逻辑和数据问题,只需要空出对应的位置,用于放置数据. 在设计和修改的时候,要解决的只是HTML的结构,代码看起来干净利落,做起来也是干净利落.
UI直接将程序逻辑的任务丢给BLL,BLL就开始构建具体的实现细节.BLL的创建依赖于业务. 例如一个文章系统,BLL_Aticle就表示它是用于对文章的处理的.BLL_Aticle可以提供给UI一个文章列表的recordset,显示在UI的预留位置. 当BLL_Aticle需要从数据库中获取数据的时候,就将任务丢给DAL层
DAL层专门负责和数据库打交道,它从BLL获取参数,组织一个有效的SQL,建立数据库连接,执行SQL进行更新或获取,将返回的数据交给BLL.
每一部分的业务都集中于一个UI-BLL-DAL的链中,上下清晰了然. 至于是怎样的便于管理和扩展,将在后面结合实例进行分析.
复杂的生命形式必有复杂的生存法则,若想在自己的项目中应用好三层架构,需要多用点心体会其中的应用法则.
我对三层架构的理解还不够深,这些文章能算是抛砖引玉就不错了.大家在阅读当中不要局限于我所构思的法则,要多向具体的应用中去实践,根据具体情况,寻出自己的法则. 有所感悟,就记得写下来,这种感悟是进步的契机,但必然不是最终的结果.有了感悟就拿去应用,可以发现它的优劣,继续完善
三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。
三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下，单层或胖客户对面器的要求太高。
三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。
三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
㈦ 求一张网络三层架构的图
三层网络架构是采用层次化架构的三层网络。
三层网络架构设计的网络有三个层次：核心层（网络的高速交换主干）、汇聚层（提供基于策略的连接）、接入层 （将工作站接入网络）。
(7)web三层架构实例扩展阅读：
三层网络结构短板
1、不断地改变的三层网络结构数据中心网络传输模式。
2、网络收敛：三层网络结构中，同一个物理网络中的储存网络和通信网络，主机和阵列之间的数据传输通过储存网络来传输，在逻辑拓扑上就像是直接连接的一样
3、虚拟化：将物理客户端向虚拟客户端转化，虚拟化服务器是未来发展的主流和趋势，它使得三层网络结构的网络节点的移动变得非常简单。
4、如果三层网络结构上主机需要通过高速带宽相互访问，但通过层层的uplink口，会导致潜在的、而且非常明显的性能衰减。三层网络结构的原始设计更会加剧这种性能衰减，由于生成树协议会防止冗余链路存在环路，双上行链路接入交换机只能使用一个指定的网络接口链接。
5、横向网络（east-west）在纵向设计的三层网络结构中传输数据会带有传输的瓶颈，因为数据经过了许多不必要的节点（如路由和交换机等设备）。
㈧ 深入浅出C#三层架构
本文用一个示例来介绍如何建设一个三层架构的项目 并说明项目中各个文件所处的层次与作用 写本文的目的 不是为了说明自己的这个方法有多薯让高对 而是希望给那些初学三层架构却不知从何入手的朋友提供一点帮助 因为网上的文章 大多是注重理论的介绍 而忽略了具体的实践应用 或者有示例但讲得不透彻 导致看了之后 理论上又滑帆学习了一遍 但还是不知道代码怎么写 所以想从这个方面入手写一下 让从来没做过三层架构的初学者也能照猫画虎 写出代码来 文中的代码是伪代码 仅用来阐明思路
正文
一提三层架构 大家都知道是表现层（UI） 业务逻辑层（BLL）和数据访问层（DAL） 而且每层如何细分也都有很多的方法 但具体代码怎么写 到底那些文件算在哪一层 却是模模糊糊的 下面用一个简单的例子来带领大家实战三层架构的项目 这个例子只有一个功能 就是用户的简单管理
首先建立一个空白解决方案 添加如下项目及文件
添加ASP NET Web Application项目 命名为UI 新建Web Form类型文件User aspx（含User aspx cs）
添加ClassLibrary项目 命名为BLL 新建Class类型文件UserBLL cs
添加ClassLibrary项目 命名为DAL 新建Class类型文件UserDAL cs 添加SQLHelper引用 （这个是微软的数据访问类 也可以不用 直接编写所有的数据访问代码 我一般用自己写的数据访问类DataAccessHelper ）
添加ClassLibrary项目 命名为Model 新建Class类型文件UserModel cs
添加ClassLibrary项目 命名为IDAL 新建Interface类型文件IUserDAL cs
添加ClassLibrary项目 命名为ClassFactory
相信大家已经看出来了 这个和Petshop的示例没什么区别 而且更简单 因为在下也是通过Petshop学习三层架构的 但一些朋友对于这几个项目所处的层次 以及它们之间的关系 可能比较模糊 这里逐个说明一下
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负责逻辑处理 继续往下看 这时提出了一个新需求 要求在每个用户的前面加一个图标 生动地表现出用户的性别 而且不满 岁的用儿童图标表示 这个需求的实现 就轮到User aspx cs来做了 这种情况下User aspx cs才算有了真正的用途
NewBLL cs
添加如下方法
public IList<UserInfo> 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中也就有了逻辑处理的代码
UserModel cs
实体类 这个东西 大家可能觉得不好分层 包括我以前在内 是这样理解的 UI?àModel?àBLL?àModel?àDAL 如此则认为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的支持就行 然后前台增加会员卡一项内容的表现与处理即可
UserDAL cs
public IList<UserInfo> 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 一个可以随意弃置的部分 又怎么能成为三层架构中的一层呢
可以这样定义 与数据源操作有关的代码 就应该放在数据访问层中 属于数据访问层
IUserDAL
数据访问层接口 这又是一个可有可无的东西 因为Petshop中带了它和ClassFactory类工厂 所以有些项目不论需不需要支持多数据源 都把这两个东西做了进来 有的甚至不建ClassFactory而只建了IDAL 然后 IUserDAL iUserDal = new UserDAL（） 不知意义何在 这就完全是画虎不成反类犬了
许多人在这里有一个误解 那就是以为存在这样的关系 BLL?àIDAL?àDAL 认为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 无需其它操作等等 本来想在文中加入一些具体的代码的 但感觉不是很必要 如果大家觉得需要的话 我再补充吧
lishixin/Article/program/net/201311/11365
㈨ ASp.net 剖析三层架构
本文不是从理论的角度来探讨三层架构，而是用一个示例来介绍如何建设一个三层架构的项目，并说明项目中各个文件所处的层次与作用。写本文的目的，不是为了说明自己的这个方法有多对，别人的肯定不对，而是希望给那些初学三层架构却不知从何入手的朋友提供一点帮助。因为网上的文章，大多是注重理论的介绍，而忽略了具体的实践应用，或者有示例但讲得不透彻。导致看了之后，理论上又学习了一遍，但还是不知道代码怎么写。所以想从这个方面入手写一下晌如，让从来没做过三层架构的初学者也能照猫画虎，写出代码来。文章表述的是笔者个人对三层架构的认识，肯定有许多不足的地方，欢迎大家指正，小弟也会根据反馈来修改这篇文章。文中的代码是伪代码，仅用来阐明思路。
一提三层行滑架构，大家都知道是表现层（UI），业务逻辑层（BLL）和数据访问层（DAL），而且每层如何细分也都有很多的方法。但具体代码怎么写，到底那些文件算在哪一层，却是模模糊糊的。下面用一个简单的例子来带领大家实战三层架构的项目，这个例子只有一个功能，就是用户的简单管理。
首先建立一个空白解决方案，添加如下项目及文件
1、添加 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 IListUserInfo 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
实体类，这个东西，大家可能觉得不好分层。包括我以前在内，是这样理解的：UI?àModel?àBLL?àModel?àDAL,如此则认为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 IListUserInfo 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（）；",不知意义何在。这就完全是画虎不成反类犬了。
许多人在这里有一个误解，那就是以为存在这样的关系：BLL?àIDAL?àDAL,认为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,无需其它操作等等。本来想在文中加入一些具体的代码的，但感觉不是很必要，如果大家觉得需要的话，我再补充吧。
总结：不要因为某个层对你来说没用，或者实现起来特别简单，就认为它没有必要，或者摒弃它，或者挪作它用。只要进行了分层，不管是几层，每一层都要有明确的目的和功能实现，而不要被实际过程所左右，造成同一类文件位于不同层的情况发生。也不要出现同一层实现了不同的功能的情况发生。
㈩ 一个成熟的javaWeb项目包含哪些层
一般是三层架构
表现层 web
业务层 service
持久层