三層架構

 

                                                                                                                     三層架構

 

 

以前对ASP.NET的三层构架的理解一直是很模糊的。看了很多资料，反倒更不宜理解。于是后来就有了一种很狭义的理解：表示层就是页面展示的东西(XX.aspx文件)；业务层就是实现数据库操作用来在页面显示的过程(XX.aspx.cs文件)；还有就是数据层是数据库。
    两种的思想是完全不同的，顿时觉得思想豁然开朗，也似乎明白了三层架构的含义：表示层是页面展示的东西(XX.aspx)；业务逻辑层是调用数据访问层的类获取数据用来在页面显示的过程(XX.aspx.cs文件)；数据访问层就是一些访问数据库获取数据的类 (.cs类文件)。 在跟朋友的讨论中，突然发现这种想法也是极其狭义的。
  关于三层架构的资料，结果发现好多版本不一。在参考了大量的文章后发现：三层架构本身就是一个很模糊的概念(或者说至少有一大批人认识不足)，没有人说那种方法就是标准的。

        那么，到现在我也该形成我自己的思想，这种理解或许仍旧是狭义的，但他更进一步接近大家的描述了。表示层包含.aspx和.aspx.cs文件；业务逻辑层就是通过调用数据访问层的方法来获取数据的类，表现为cs类文件；数据访问层封装了访问数据库的各种方法的类，一般表现为一个cs类文件，其作用主要就是使得对不同数据库有不同的类，但是对这些类的调用是统一的。


用一个简单的代码就是：

    <textarea id="Content" runat="server"></textarea>
    <input type="button" id="Post" runat="server" />

    // ----------------------------------------
    // 在外观层，当用户点击发送按钮后
    // ----------------------------------------
    private void Post_ServerClick(object sender, EventArgs e)
    {
        LeaveWord lword=new LeaveWord();
        lword.Content=Content.Value;
        lword.Post();
    }

    // ----------------------------------------
    // 在商业逻辑层，定义 LeaveWord 类
    // ----------------------------------------
    public class LeaveWord
    {
        public string Content;

        public void Post()
        {
            new LWordData().Post(this.Content);
        }
    }

    // ----------------------------------------
    // 数据库层，定义发送方法
    // ----------------------------------------
    public class LWordData
    {
        public void Post(string content)
        {
            // 打开数据库，将 content 插入到表中
        }
    }

这样，外观层就不必费心数据库操作了...


理解基本正确.但是数据层已经只是数据库的操作,不应该和业务有任何关系,你可以参考SqlHelper.cs
提醒一点,系统的"层"是对代码的一种逻辑划分,并不是一定要三层,假设你的系统很简单,就一个页面,那一层就可以,如果系统很复杂,也可能是n层.
差不离了，核心就是外层绝对不会涉及任何数据处理，他的任务是设置界面，获取数据，输出数据
业务层最重要，所有数据处理在这里，如何运用外层提供的数据处理业务
数据库层一般都建议调用存储过程，返回数据集或其他所需数据;.net的那两个例子很好，多学习一下.
一个原则：
上层调下层
上层对下层是不可见的
设计时，表现层只调用逻辑层，表现层主要是取得页面的数据传到逻辑层，和把从逻辑层得到的数据显示到页面上。
逻辑层负责把数据加工整理传到数据层和把从数据层取得的数据加工
数据层就只负责把数据对数据库操作

业务逻辑层就是给上层和下层下达命令和调节行为的中间层，这样说易于理解一点了吧？



[冷枫].NET三层经典架构PetShop3.0分析开发者在线 Builder.com.cn 更新时间:2007-09-22作者：冷枫 来源:CSDN
本文关键词： 冷枫 .net 架构 PetShop
petshop是C#实现的petstore，具体和技术无关的情况就不多介绍了。
petshop3.0比petshop1和2都有了较大的改变，主要是设计方面的。看一下里面的8个工程和1个站点就知道它肯定分了不少层。
一.概况介绍。
Model：
模型层，封装业务实体，一般和数据库模式对应。
例如：
      public class AccountInfo {

              // Internal member variables
              private string _userId;
              private string _password;
              private string _email;
              private AddressInfo _address;
              private string _language;
              private string _category;
              private bool _showFavorites;
              private bool _showBanners;
              。。。
      }
IDAL：
数据访问接口层，主要是一些dao接口。
例如：
      public interface IAccount
      {
              AccountInfo SignIn(string userId, string password);
              AddressInfo GetAddress(string userId);
              void Insert(AccountInfo account);
              void Update(AccountInfo Account);
      }

OracleDAL：
oracle实现的数据访问层。

SQLServerDAL：
sql实现的数据访问层。
OracleDAL和SQLServerDAL中的类都实现了IDAL中的接口。属于dao实现。

DALFactory
负责确定是使用oracle实现还是mssql实现。通过在web.config中的配置确定使用哪一个dal实现（通过反射，动态生成访问类是PetShop.SQLServerDAL还是PetShop.OracleDAL命名空间中的类）。
              <add key="WebDAL" value="PetShop.SQLServerDAL"/>
              <add key="OrdersDAL" value="PetShop.SQLServerDAL"/>
      public class Account
      {
              public static PetShop.IDAL.IAccount Create()
              {                 
                    /// Look up the DAL implementation we should be using
                    string path = System.Configuration.ConfigurationSettings.AppSettings["WebDAL"];
                    string className = path + ".Account";

                    // Using the evidence given in the config file load the appropriate assembly and class
                    return (PetShop.IDAL.IAccount) Assembly.Load(path).CreateInstance(className);
              }
      }

BLL：
业务访问层。通过DALFactory，读取配置，决定使用何种dal实现。
      public class Account {         
              public AccountInfo SignIn(string userId, string password) {


                    if ((userId.Trim() == string.Empty) || (password.Trim() == string.Empty))
                            return null;

                    // 通过DALFactory调用具体的dal实现。
                    IAccount dal = PetShop.DALFactory.Account.Create();

                    // Try to sign in with the given credentials
                    AccountInfo account = dal.SignIn(userId, password);

                    // Return the account
                    return account;
              }
              。。。
}

Web：
表现层，主要包括了Web 页面（aspx）和用户控件（ascx）控件及自定义服务器控件SimplePager和ViewStatePager。

Utility：
公用模块，一组帮助器类，其他业务层和数据访问层可能会使用到的一些公用方法。

分层如何使系统更灵活
      学习面向对象设计和设计模式和架构模式，我们可以知道，设计的重要目的，一个是可重用，一个是可维护还有就是可扩展性。
      面向对象技术本身就提供了很多可重用得机制，通过继承和组合可以使代码较大程度的重用。另外，我们需要通过设计，抽象出基本的概念，对这些概念进行重用。重用可以提高系统的可维护性，因为重用的东西一般经过了充分的测试和长时间的考验，比我们自己重复发明的轮子的质量更容易保证。
可扩展，继承和重载是扩展的方式，但他们是语言级的，我们需要通过设计达到系统级的可扩展。
这里主要结合petshop的分层设计和实现谈一下这几个设计的指标。
      上面介绍了各个层，各层的调用关系是这样的：
web层-->BLL(使用Model)-->DALFactory（通过IDAL）-->具体DAL实现层（oracle或ms sql）-->持久存储。
      这样，各层至于相邻的层交互，通过定义良好的接口，层内部的实现对其他层来说关系是不大的。这很符合软件工程的思想，因为定义好了接口后，开发人员就可以按照自己的特长实现各自的层，并且容易测试，因此可以提高软件的开发效率和开发质量。
从架构和源码实现上我们可以看到，数据层的灵活性，可扩展性和可维护性是通过DALFactory层实现的。我们知道，由于采用面向接口编程这一原则，DALFactory可以通过配置文件信息来确定使用哪一个IDAL实现，这样我们就可以在部署时通过修改配置文件来适应客户的数据库要求。当然这也要求，具体的数据库实现层要遵循特定的命名约定，比如对于Account实现，sql和oracle中对应的类要有相同的名字和构造函数（现在是必须有默认构造函数，否则无法初始化），当然所在的名称空间要不同。
以后，当我们需要实现mysql或db2的数据实现层的时候，我们只需要通过mysql或db2按照上面的命名约定实现，在web.config文件中进行配置就可以了（可扩展和可维护性）。而且，如果客户原先使用mssql后来要使用oracle，然后…… 如此反复的折腾，我们也不会挠头，因为我们原先的实现可重用，新的要求，可扩展。另一方面，对于同一个数据库我们也可以采用不同的实现方法，比如ado.net（又分为直接的sql和存储过程实现），orm框架，ibati式的半orm框架，我们可以为每种这样的实现建立一个工程，灵活的选择，而不是仅在原来的基础上修改。这就是petshop数据访问层向我们展示的为什么要这么分层。
      其实现在的很多框架和系统为了实现灵活性都是通过配置实现的，因为修改配置
不像修改源代码那样需要重新发布，而且就像petshop，OracleDAL，SQLServerDAL的两个dll可以同时存在，需要使用哪一个就配置哪一个就可以了。


Duwamish 7.0 结构分为四个逻辑层：
Web 层
Web 层为客户端提供对应用程序的访问。这一层是作为 Duwamish.sln 解决方案文件中的 Web 项目实现的。Web 层由 ASP .NET Web 窗体和代码隐藏文件组成。Web 窗体只是用 HTML 提供用户操作，而代码隐藏文件实现各种控件的事件处理。
业务外观层
业务外观层为 Web 层提供处理帐户、类别浏览和购书的界面。这一层是作为 Duwamish.sln 解决方案文件中的 BusinessFacade 项目实现的。业务外观层用作隔离层，它将用户界面与各种业务功能的实现隔离开来。除了低级系统和支持功能之外，对数据库服务器的所有调用都是通过此程序集进行的。
业务规则层
业务规则层是作为 Duwamish.sln 解决方案文件中的 BusinessRules 项目实现的，它包含各种业务规则和逻辑的实现。业务规则完成如客户帐户和书籍订单的验证这样的任务。
数据访问层 休闲 居 编辑
数据访问层为业务规则层提供数据服务。这一层是作为 Duwamish.sln 解决方案文件中的 DataAccess 项目实现的。
注意  有关 Duwamish 7.0 Visual Studio .NET 解决方案文件的进一步信息，请参阅Solution File and Environment Settings。

除了上述四个逻辑层外，Duwamish 7.0 还包含封装在 Duwamish.sln 解决方案文件中的 Common 项目内的共享函数。Common 层包含用于在各层间传递信息的数据集。Common 项目还包含 Duwamish.sln 解决方案文件中的 SystemFramework 项目内的应用程序配置和跟踪类。
结构关系图

层间交互

Duwamish 7.0 结构允许分布式或非分布式部署方案。有关部署选项的详细信息，请参阅Setup and Deployment Scenarios of Duwamish 7.0。这两种部署方案都有可能，因为 .NET 程序集和 Web 层是独立的可部署单元。尽管这些程序集可使用任何配置进行物理部署，但由于性能原因，应在选择部署方案之前考虑层间交互。例如，业务外观层、业务规则层和数据访问层之间的紧密交互要求将这些单元放在一起。为了阐明此紧密交互，请参阅Checkout中的序列关系图。


刚刚来了一个灵感，感觉三层架构是不是要怎么分解一下呢？（侧重于b/s架构）

UI层：

浏览器 —— 要考虑一下不同的浏览器、和插件若干
js脚本 —— ajax这一类的，数据验证了什么的。
显示数据 —— 放在.aspx 页面
提供数据 —— 放在.aspx.cs 页面

逻辑层：

业务逻辑 —— 承上启下，但是大多数情况只用一行代码就可以实现了。
数据逻辑 —— 组合SQL语句，存储过程的话就是给参数赋值了

数据层：

SQLHelp —— 具有类似功能的东东
数据库里的存储过程 —— 不用存储过程的话就略掉
数据库里的视图 —— 同上，我比较喜欢用
数据库里的表 —— 基础的东东了，对于客户来说，里面的数据是最最重要的了。