2006年8月存档-纯技术视点

IIS 的一个不足和一个使用建议

经常借用别人公司的一台托管的服务器上传下载些资料，顺便也帮人盯着服务器的配置与安全，前两天发现，系统盘 10G 硬盘空间没剩多少了，进去一看，原来 IIS 的日志文件（%windir%\system32\logfiles）下有5－6个G的日志文件，每天的日志约有 30-40M，于是把这些日志文件备份出来，压缩存储了一下，立刻节省了大量磁盘空间出来。

这个网站的访问里并不大，但日志文件为什么这么大呢，打开一看，IIS 的日志记录是很详细完整，但是仔细一看，好多行信息都是 jpg 和 gif ，这可能由于这台服务器是公司/产品宣传的缘故，所以图像文件较多，因此当访问一个页面时，会记录 10-20 条日志信息，从日志的真正用处来看，这些多余的图像文件的访问日志并不需要，而且，这么多的日志信息显然消耗了服务器的计算、IO、存储资源，影响高并发时的性能。

于是想在 IIS 的日志里对记录的 URI 资源类型做一下限制，很遗憾，没有发现这样的选项，在 Google 上似乎也没有找到替代的做法，这样看来，这好象是 IIS 日志记录功能的一个不足之处。

更新：感谢思归提供的解决办法，我把 Images 目录的日志记录取消了之后，日志文件在大小见下图：

另外再次极力推荐一下 IIS 的 gzip 功能，最近一直在研究其对性能和带宽的影响，应该来说，对于绝大多数互联网上的服务器来说，CPU 的资源比带宽资源的利用率更低，因此应该利用这些闲置的 CPU 资源来压缩页面，降低带宽点用，提高响应速度，而且，对于静态内容来说，这种压缩可以生成临时文件，避免每次访问都对资源进行压缩，因此对 CPU 资源的影响也是非常小的。对于大型企业来说，要在集中位置部署一个 B/S 的系统，那么利用 gzip 能大大节省租用运营商通讯线路带来的成本（利用 Internet Security and Accelerator 提供的 HTTP 压缩和缓存功能，也可以达到同样的目的）

在 port80software 这个网站上，提供了一在线测试工具，可能对你的网站进行测试，以确定其是否提供 gzip 压缩以及压缩比重、传输速度的提升等。

posted on 2006-08-29 22:23:00 by moslem 评论(9) 阅读(6190)

ASP.NET 常见参考项目的 UI、BLL 、Model 、 DAL 分析

应用/项目名称	UI层实现	Business Model & Logic Layer 实现	Data Access Layer 实现
Personal Web Site Starter Kit	在ASP.NET页面上直接利用 ObjectDataSource 来绑定 PhotoManager 中的方法来获取数据、更新数据	两个数据实体类（Album、Photo），一个管理类（PhotoManager）自行解决数据库连接、使用 SqlCommand 来调用存储过程来完成
Club Web Site Starter Kit	在ASP.NET页面上直接利用 SqlDataSource 来获取数据、更新数据	只有一些简单的 Helper/Utility类，业务逻辑大多在页面上实现	有一个DataSet，提取 Member表的数据，在自己的数据库中扩充了 SqlMembershipProvider的字段
Classifieds Site Starter Kit	在ASP.NET页面上，增/删/改主要是利用FormView调用BLL中的ModelDB来实现，数据列表主要利用ModelCache的List和ModelDB返回的ModelDataTable来绑定	1) BLL中实现了 ModelDB的类，调用DAL中的DataSet来进行数据更新，如果是查询数据（GetModelList），则得到 ModelDataComponent.ModelDataTable，这是数据集自动生成代码中的一个类 2) 在 App_Code 的Web目录中，主要实现了部分实体在 HTTP Context中的Cache功能，建立了 CachedModel（数据实体类）及其管理对象 ModelCache，后者主要是将BLL层的ModelDB的Retrive结果DataTable转成 List	全是ASP.NET 2.0 中的DataSet，实现了所有表数据的获取与更新，它是调用存储过程来实现的
Commerce Starter Kit	在ASP.NET页面上，有一些是直接调用 ModelManager对象来完成用户交互，有一些则是利用 ObjectDataSource 绑定 ModelManager 来达到同样功能对于某些操作，如果没有对应的 ModelManager 则直接使用 SqlDataSource	1) 在Objects目录下，定义了数据实体类，包含所有属性的Get/Set方法的定义，没有实例化方法，而是使用 void Load(IDataReader)来初始化，其中有一个对象（ShoppingCartItems），则继承至DataTable，利用BuildDataTable（）来进行初始化 2) 利用数个 ModelProvider 将与数据库的主要交互功能封装起来，提供了实体层次的CRUD 3) 在 BLL 目录下，有数个 ModelManager，提供从业务层面对 Model 的操作，其中主要是调用 ModelProvider来完成具体的操作	在 ModelProvider项目中中，先定义ModelProvider抽象类，再由 SqlModelProvider 来继承，后者中利用 SqlHelper 来完成数据访问，主要是调用存储过程
Duwamish 7.1 (.NET 1.1）	调用BusinessFacade中的 OrderSystem 和 ProductSystem 中的方法完成用户交互，这主要是调用DAL层的相关对象来完成的	1) ModelData，继承自System.Data.DataSet，在构造函数里调用BuildDataTables()来初始化一个DataTable用来存储Model数据 2) 在BusinessFacade和BusinessRule中，实现了与业务逻辑有关的内容，调用数据层的 Models 来完成数据访问	实现了数个 Models对象，提供了对于 ModelData的CRUD方法，它也是调用 SqlHelper 来完成与数据库的交互
Jobs Site Starter Kit	利用 ObjectDataSource 绑定 Model 类，Command 主要是调用 Model 的 CRUD方法	在 Model 对象中定义了所有属性和CRUD方法，实现时调用了 DAL 的 DBAccess 对象，也使用了诸如 SqlParameter 等对象	只有一个类 DBAccess ，属于工具类，类似于 SqlHelper，它是利用 System.Data.SqlClient 来实现的，如果向其他数据库移植，代码量不大
Timer Tracker Starter Kit	利用 ObjectDataSource 绑定 Model 类，Command 主要是调用 Model 的 CRUD方法	在 Model 对象中定义了所有属性和CRUD方法	DataAccess：抽象类，定义了DAL层需要实现所有 Model 的 CRUD 对应的数据访问方法 DataAccessHelper：工厂类，利用配置创建相应的 DataAccess 对象 SqlDataAccess：DataAccess 的 SQL Server 实现，其中也包含一些类似于SqlHelper 的通用方法以简化代码
.Text 0.95 (.NET 1.1)	大多数是调用 Model有直接调用 SqlDataProvider 来获取数据、更新数据	在Dottext.Framework 的 Component 中定义了业务实体 Model 和 ModelCollection，在在Dottext.Framework定义了 Models 类，主要用提供 Model 的 CRUD 方法，其中的 R 返回 ModelCollection	在Dottext.Framework 的 Data 中定义了 IDbProvider和 IDTOProvider 接口，然后提供了 DataDTOProvider 和 SqlDbProvider 的实现，其中调用了 SqlHelper 类
Community Server 2.1 SDK (.NET 1.1 & 2.0)	直接调用 Models 的方法来获取数据、更新数据等	在 CommunityServerComponents 项目的 Components 中定义 Model 类，其中仅包含属性定义及构造函数，另外定义了 Models 类，其中实现了 Model 的 CRUD 方法，它是调用 Provider 下的 CommonDataProvider 来完成数据访问的	在 CommunityServerComponents 项目的 Proivder 中，利用抽象类CommonDataProvider 定义了所有 BLL & Model 层需要的数据访问方法，然后在 SqlDataProvider 中项目中使用 SqlDataProvider 继承此类，完成与 SQL Server 数据库的交互
.Pet Shop 4.0	在 ASP.NET 的页面上，大多是利用代码来调用 BLL 层的 Model 对象来获取数据、更新数据	Model 项目中定义了所有的业务实体 ModelInfo BLL 项目中定义业务实体 Model ，其中包含业务视角的 CRUD 方法，它们是调用 IDAL 中的 IModel 的 CRUD 方法来实现的	IDAL 项目中有多个接口定义 IModel，其中定义了需要实现的 Model 的 CRUD 方法 SqlServerDAL 和 OracleDAL 分别在两种数据库上实现了 IDAL DALFactory 为工厂类，负责根据配置返回相应的 IDAL 的 IModel 实现类 DBUtility 是 SQL Server 和 Oracle 数据库操作的工具类，主要是 SQLHelper 和 OracleHelper

简单个人评价：

Personal Web Site Starter Kit：简单，供初学者参考之用
Club Web Site Starter Kit：对标准 MemberShip 的扩充值得一看
Classifieds Site Starter Kit：结构较为清晰，利用 DataSet 简化了大量 SQL 代码的编写
Commerce Starter Kit：利用了 Provider 模型，有些小瑕疵，如界UI层有 SqlDataSource，Model 中有 DataTable
Duwamish 7.1：架构比较清晰，但Model 继承自 DataSet ，因此其 BuildDataTables 和 Models 中的CURD 方法较为麻烦，代码量较大
Jobs Site Starter Kit：简单实用，有些缺点，如 Model 的 CRUD 方法的 SqlParameter 造成 BLL 和 DAL 无法完全隔离
Timer Tracker Starter Kit：一种架构清晰、较好的实现模式，只是代码量稍大
.Text 0.95：基于 .NET 1.1 ，因此 BLL 层稍显复杂，DAL 层代码量也较大
Community Server 2.1：它同时兼容 .NET 1.1 和 .NET 2.0 ，因此没有利用 .NET 2.0 的许多特性，但其 Provider 的模式较为清晰
.Pet Shop 4.0：架构清晰

注：上述分析以数据访问为主，本 Post 是使用 Windows Live Write 来编写完成

posted on 2006-08-26 14:52:00 by moslem 评论(12) 阅读(18097)

数据访问层实现的一些个人想法

个人感觉数据访问层应该实现以下几个主要目的：

1）分离业务层与数据层

2）屏蔽具体数据库的差异（如SQLServer、Oracle、OLEDB、ODBC等）

3）简化数据访问层的代码，经常写一些 Parameter 的设定是很无聊的事情）

先下载并研究了一下Enterprise Library 2.0 ，发现其中的Data Access Application Block有点复杂了，有近 40 个类文件，还需要引用 Configuration、Common、ObjectBuilder 等项目，本身就是一个很大的项目了... 个人觉得还不如上一个版本中的 SQLHelper 对象那么简单方便（Pet Shop 4.0 中的 DabaAccess 项目里就是用 OracleHelper和SQLHelper来实现的）

再来研究Pet Shop 4.0 ，其中主要对象层次一般是（假设Model是业务对象）：

ModelInfo <- Model -> IDAL <- SQLServerDAL(或OracleDAL)

其中：

ModelInfo 是瘦的业务实体数据对象
Model 实现 ModelInfo 的管理（增、删、改、查询）等，调用 IDAL 来实现
IDAL 是数据访问层的接口定义
SQLServerDAL 是 IDAL 在 SQLServer 上的实现，如果是 Oracle，可以利用 OracleDAL 来实现

貌视还不错的结构，只是 DAL 层的里面的代码还是比较多，好多SQL、好多Parameter的操作

再看看 Visual Studio 2005 中带的"个人网站的初学者工具包"的数据访问代码，它只是简单在App_Code中有 Model(瘦的业务实体数据对象)、ModelManager(管理对象，数据层的访问也在其中实现)的两个对象，数据库也只是SQL Server，较为简单，但也不易扩展。

我的一点想法：

1）Enterprise Library 2.0 有些庞大和重量级，学习曲线太长，谨慎使用

2）Visual Studio 2005 中的数据集对象（DataSet）是个好东西，可以简化很多SQL语句的编写和参数的设定

3）Pet Shop 4.0 的总体架构还是不错的（Model <- ModelInfo -> IDAL <- SQLServerDAL），值得参考，但是在SQLServerDAL 和 OracleDAL 不用手动去编写代码，而是调用利用 DataSet 自动生成的代码来实现（SQLServer、Oracle、OLEDB或ODBC等），简单的业务对象管理动作应該是能直接利用DataSet提供的方法直接实现，如果是复杂的数据层操作，可以自己编写代码来实现（如多个表之间的数据操作）

4）musicland 和 JGTM 2006 也提供了一种不错的实现方式，具体参考这篇Post

这样的话，开始提到的三个目的都能达到了。

posted on 2006-08-22 10:13:00 by moslem 评论(15) 阅读(8513)

纯技术视点

导航

关于

标签

每月存档

最新留言

广告

IIS 的一个不足和一个使用建议

推荐一个不错的 ASP.NET 2.0 控件

ASP.NET 常见参考项目的 UI、BLL 、Model 、 DAL 分析

数据访问层实现的一些个人想法