博客园_铁目诱惑

谈谈ASP.NET皮肤机制的实现

2010-10-31T15:35:00Z

做一个WEB程序，能够在尽量修改极少程序代码的情况下，轻松制定皮肤以及切换皮肤，应该都是需要的，谁也不想，在网站界面想要改版的时候，要改一大片逻辑代码。

一个合格的皮肤机制体系的实现，应该要做到以下几点：

->页面模板上要极少拥有逻辑代码(如果模板上拥有大量逻辑代码，那估计这个也不叫作模板了)。
->能够轻松改变页面布局，同时不影响程序代码(.cs)。
->新模板的定制，基本上能由皮肤制作者参照旧模板自行完成，不需要开发人员太多介入。
->保持性能。

然后，来看看，都有哪些方法大家用来实现所谓的皮肤机制，同时进行各个方法的一些个人说明。

1. 改变页面调用的CSS文件来换肤。

这一个，严格上来讲，不应该算作皮肤机制。虽然CSS非常强大，也能够通过它来任意改变页面元素布局，但它的HTML始终是不变的，所以局限性是非常大的。

优点：完全不影响性能，甚至可以完全不由服务端代码来管理它的变换，可以使用JS来切换皮肤（由此，在我们有一套完美皮肤机制的情况下，这种方法，可以完全不与此机制冲突，让用户在客户端作更多的个性化）。

缺点：如果作为核心皮肤机制的话，非常有局限性。

示例：如QQ.COM, 114LA.COM上面的一些可点击的小色块，就是改变调用的CSS文件来实现换肤。

2. 读取模板文件，替换标识符为要显示的内容与数据输出。

这一个方法的灵活性比较高，每套皮肤可以有自己的布局，有自己的个性。

实现：比如模板中有一个标识$Subject，程序代码会把它替换成文章标题，然后有一个标识块<!—Loop[ArticleList]--><h1>$Subject</h1><div>$Content</div>，程序代码会把它替换成一个文章列表，最后输出处理完所有标识符的内容。

通常，我们会缓存读取到的模板内容，但字符串的替换始终不可避免，或者也会把替换过的内容也缓存起来，但这样子，就等于要缓存模板内容以及替换过的内容，占用了两份似乎挺重复内容的内存（为什么？不然总不该每次数据有改变的时候就去作IO操作读取操作读模板文件吧，这似乎比字符串替换性能更差）。

优点：模板灵活程度很高，可以随便改动页面布局。

缺点：影响性能，开发人员维护难，必须有特定的标识符来表示页面变量，后期维护可能会带来非常多的问题。

3. 使用ASP.NET的App_Themes。

这一个方法，应该是极差的一个方法，根本只是ASP.NET的一个小纂头，鸡肋，基本上不实用。

实现：比如，定制一个BUTTON的样式是这样子的，<asp:buttonrunat="server" BackColor="lightblue"ForeColor="black" />，类似这样的代码，存在于.skin文件中。然后它的换肤机制如下，＜%@ Page Language="C#" Theme="default" %＞。在App_Themes目录下，是各套皮肤的独立文件夹，各个文件夹包含皮肤的样式以及图片文件等等，也可以包含.skin文件。

优点：只有ASP.NET才有

缺点：包含了第一种方法的缺点，.skin的样式定制方式还要严重依赖使用ASP.NET服务端控件，同时也影响性能，灵活性也极低。

4. 动态载入.ASCX文件（ASP.NET用户控件）|| 使用.master(母版)。

这个方法，应该也是很多使用ASP.NET的人使用的方法，有时候，它还会与第三种方法结合使用。如果对性能需求不是很严格的话，中小型项目可以使用。

实现：使用LoadControl()动态载入.ASCX文件或(与)指定页面的MasterPageFile（目标皮肤文件夹的）实现(通常.ascx与.master还会结合使用)。

优点：灵活性极高，每个皮肤有独立的布局，直接使用了.CS文件的变量与方法ETC…甚至每套皮肤还有自己独立的代码文件。

缺点：影响性能。有兴趣可以自己去反编译LoadControl方法。同时，在页面要使用<%%>这种代码块，有时候感觉也有点不雅。

5. Xml + xslt

传说xml取代html是趋势？？不清楚，不了解。应该不可能。此种方法我没有深入了解过，不过大概实现应该是要这样子？每一个XML（输出数据）会有一个对应的XSL文件（控制样式）。如下：

<?xml version="1.0"encoding="ISO-8859-1" ?>

<breakfast_menu>
<food>
<name>Belgian Waffles</name>
<price>$5.95</price>
<description>two of our famous Belgian Waffles with plenty of real maplesyrup</description>
<calories>650</calories>
</food>

<food>
<name>Cakes</name>
<price>$1.95</price>
<description>sweet cakes</description>
<calories>2650</calories>
</food>

</breakfast_menu>

<?xmlversion="1.0" encoding="ISO-8859-1" ?>

<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns="http://www.w3.org/1999/xhtml">
<body style="font-family:Arial,helvetica,sans-serif;font-size:12pt;background-color:#EEEEEE">
<xsl:for-each select="breakfast_menu/food">
 <div style="background-color:teal;color:white;padding:4px">
 <span style="font-weight:bold;color:white">
<xsl:value-of select="name" />
</span>
<xsl:value-of select="price" />
</div>
 <divstyle="margin-left:20px;margin-bottom:1em;font-size:10pt">
<xsl:value-of select="description" />
 <span style="font-style:italic">
<xsl:value-of select="calories" />
</span>
</div>
</xsl:for-each>
</body>

</html>

这样子做，有什么好处么，我没有体验到。

6. 读取模板文件，生成.aspx文件到每套皮肤的独立文件夹下，通过地址重写指定到这些文件夹。

这个方法的最终效果对于用户来说，和第二种方法应该是差不多的，优点就是性能比较高，而且还能直接使用.CS代码里面的变量方法ETC…另外，也可以不会有<%%>代码块的存在，可以存在自己的模板语言，如同第二种方法的$Subject, <!—Loop-->标识符一般。

优点：几乎不影响性能，只有第一次读取生成.ASPX文件需要损失性能。灵活性极高。模板代码可读性也可以实现到很高。

缺点：启动时需要读取分析时间（不过，这应该算是小问题），另外，有一套皮肤，它就要生成与之对应的一套.ASPX文件（当然这个可以解决）。

7. 利用ASP.NET2.0开始才拥有的VirtualPathProvider来实现。

虚拟文件机制。这个，应该算是第六种方法的加强版。最终的效果，和第六种差不多，只是不会生成那些.ASPX文件而已，取而代之的，便是长驻在内存中。

实现：实现两个类，一个继承至VirtualPathProvider，一个继承至SkinFile。VirtualPathProvider里有个FileExists方法，重写成判断请求的路径是否是皮肤文件路径，如果是，GetFile就实例一个SkinFile(这一个SkinFile，我们会对模板进行处理，可以拥有自己的模板语言)。另外有一个GetCacheDependency方法，可以来将模板文件作为虚拟文件机制的缓存依赖文件，一旦模板文件被修改了，它就会再重新解析模板文件。这里先不作赘述，具体的，查看MSDN的相关文档，具可了解。

优点：与6相同。

缺点：第一次启动需要损失性能(但这也不可避免)。

8. 还有更多的实现方法，还没用过，个人先不发表观点，比如：使用BuildProvider，但这一个，需要有比较强的词法分析与语法分析能力。。。。。

欢迎讨论！

本文链接

SQL SERVER索引优化系列之三：填充因子

2010-09-28T16:03:00Z

建SQL SERVER索引的时候有一个选项，即Fillfactor(填充因子)。

这个可能很少人会去注意它，但它也是比较重要的。大家可能也都知道有这个东西，但是如何去使用它，可能会比较迷糊。另外，即使你理解了它的原理，也不一定能使用好它，这个还要具体分析索引字段的更新频率等等。

记得看书知道有这么个东西，但是都是看的迷迷糊糊的，不知道干吗的，好象设置不设置都一样的。其实，像索引这些东西，当数据达到几十万上百万的时候，它的效果就表现的很明显。

填充因子定义：索引中叶级页的数据充满度。它的作用：当系统新建或重建索引时，在每一个索引页上预先留出一部分空间。使得系统在新增索引信息时能够保持索引页不分裂。它的目的是使索引的页分裂最小并对性能微调。

(图A)

看图A，通过前面说的我们知道数据是按页存的，根据定义，填充因子是指图A中的Page100(Page110,Page120,Page130)的数据的充满度。如果按默认，填充因子是为0(0和100%是一样的)，即完全充满。如果设置60%，则Page100的数据只充满空间的60%，会有40%的剩余空间。

填充因子只在创建索引时执行；索引创建后，当表中进行数据的添加、删除或更新时，不会保持填充因子。即创建索引完后添加数据，比如添加”COM”,则会添加在Page100的”CON”的前面，此时Page100的剩余空间将小于40%。因为充满度只有60%，所以”Barr”和”CON”之间会有空隙，所以”COM”将直接插入他们之间，不会照成数据移动和页分裂。如果充满度是100%即整页充满数据，则会照成”CON”及它后面的数据都向后移动1位，然后在”CON”前面插入”COM”，而Page100会大约一半的行(后半部)移到新页中以便为新行腾出空间(这种重组称为页拆分。页拆分会降低性能并使表中的数据存储产生碎片.)，在这些移动的过程中一方面速度明显下降，另一方面会产生碎片。添加完数据后要使填充因子继续保持60%则需要重建索引。

有人将填充因子比喻成下面这个例子：

为了给一个班的10个同学排一下顺序，我们可以给每一位同学一个编号，如:
a. 从1,2,3,4,5,6,7,9,10。这时，我们说填充因子是100.
此时,如果又来了新同学,而其排名要在中间某位置的话,我们就要改变许多个同学的号码,如新同学排第5位,就需要4号以后的同学号码都加1，再将新同学编为5号才行.
b.我们又可以给同学这样编号：1,3,5,7,9,11,13,15,17,19
也同样完成了顺序的排列.我们说这时填充因子是50%,此时如果来了新同学,又是排在第5位的话,那么我们只需将其号码编为8就行了.其它同学都不用变.

可见,填充因子大的时候,点用的号码空间小,耗费资源少,小的时候,占用资源加大,但操作方便,迅速.

填充因子大的时候,插入或修改记录后重新索引的工作会很大,磁盘IO操作增加,性能必然降低,但其占用空间小.填充因子小的时候,索引文件占用磁盘及内存空间相对要大,但是,系统本身重新索引所需IO操作减少,性能提高,只是多占用一些存储空间. 孰轻孰重要自已决定。

通常只有当不会对数据进行更改时(例如，在只读表中)才会使设置100%。另外,只有当在表中根据现有数据创建新索引，并且可以精确预见将来会对这些数据进行哪些更改时，将填充因子选项设置为另一个值才有用。所以填充因子不是很容易设置的。

SQL SERVER索引优化系列之一：工作原理&聚簇索引|非聚簇索引

SQL SERVER索引优化系列之二：索引性能考虑

SQL SERVER索引优化系列之三：填充因子

本文链接

SQL SERVER索引优化系列之二：索引性能考虑

2010-09-28T16:01:00Z

在前面说过了索引能极大的提高数据的检索速度，那为什么不在每一个列上建索引呢？初学者可能会困惑这个问题，而且通常不知道哪些列该建索引，哪些不该建，甚至于会把like模糊查询的列也作为索引列，其实绝大多数情况下，like是不使用索引的，只有等于,大于,IN等操作符会使用索引。SQLSERVER对于数据的插入，更新和删除，都要更新相应的索引。这无疑会大大增加更新时间。另外，如果某个数据页已满，这时如果要在该页插入数据时，就会造成页分裂产生碎片(后面还会说到)，而影响性能。所以仅当查询的性能比更新的性能更重要时才建索引。

考虑建索引的列

1. 主键
2. 外键
3. 频繁检索的列和按排序顺序频繁检索的列

通常where 后面的条件引用的列都是考虑建索引的列，模糊查询除外(如like查询)
不考虑建索引的列

1.很少或从来不在查询中引用的列
2.只有两个或若干个值的列(比如只有男和女两个值的列)
3.小表(行数很少的表，这时候SQL SERVER花费在索引上的时间比直接扫描表的时间还更长)

SQL SERVER对于建立索引的列，都要付出一定的代价来维护这个索引。另外SQLSERVER会自动分析是否使用该列的索引，比如对于只有男和女两个值的列，如果给它建立索引，SQLSERVER自行分析后，会认为改列使用索引查找的效率不大，因为返回结果集的百分比比较大，于是SQLSERVER会将统计数据记录下来，当下次查找该列时，就会根据该统计数据来决定是否要使用改列的索引。

对于返回结果集百分比比较大的列(比如有100万的数据，而查找的结果将返回50万)，SQLSERVER就可能不会使用该列上的索引，而采用全表扫描的方法。可自行测试，插入2000条数据，有1999条数据是一样的，比如ForumID为2的有1999条，ForumID为3的只有一条，这时使用

SET SHOWPLAN_TEXT ON –显示执行计划，可查看查询语句使用了哪些索引
GO

SELECT * FROM Posts WHERE ForumID=2
会发现没有使用ForumID列的索引。

SELECT * FROM Posts WHERE ForumID=3
则使用了ForumID列的索引

进行大批量插入或更新应先删除索引最后再重建索引，避免每插入或更新一条数据时都要更新相应的索引，而影响更新速度。
复合索引(指两列或多列组成的索引，通常where后面由多个列组成的条件时，可以把这些列建成一个复合索引)

1) 只有当WHERE子句中指定索引键的第一列时才使用该索引。
例子:
CREATE INDEX Posts_INDEX
ON Posts(ThreadID,ForumID)

如果SELECT * FROM Posts WHERE ForumID=2 则查询不会使用Posts_INDEX索引
而 SELECT * FROM Posts WHERE ThreadID=10 则会使用Posts_INDEX索引

2) 索引不应过大(<= 8个字节为最好，int型相当于4个字节，SmallInt相当于2个字节)。
3) 首先定义最具唯一性的列(顺序不一样，索引是不一样的)
比如:A列有30%的数据是重复的，B列有10%的列是重复的，C列有25%的数据是重复的，这时候建立索引的列的顺序应当是 B C A

建立索引还有一个比较重要的选项:填充因子。下一篇继续。

SQL SERVER索引优化系列之一：工作原理&聚簇索引|非聚簇索引

SQL SERVER索引优化系列之二：索引性能考虑

SQL SERVER索引优化系列之三：填充因子

本文链接

SQL SERVER索引优化系列之一：工作原理&聚簇索引|非聚簇索引

2010-09-28T16:00:00Z

我们来简单地看看SQL SERVER索引是如何工作的，关于索引的一些概念就不说了。

聚簇索引：

(图A)

我们来看图A,聚簇索引的结构图。
数据页就是数据库里实际存储数据的地方，可以看到是按页1页1页存的。

假设那个列是”LastName”。

因为是聚集索引,所以它是按照顺序排下来的。可以看到，索引是一棵树，首先先看一下这棵树是怎么形成的。

先看Page100和Page110的最上面，由它们形成了Page141,Page141的第一条数据是Page100的第一条数据，Page141的最后一条数据是Page110的第一条数据。同理由Page120和Page130形成Page145,Page141和Page145形成根Page140.

好了，然后来看看它是如何查找数据的。

我们来找”Rudd”这个姓。

首先它会从根即Page140开始找,因为”Rudd”的值比”Martin”大(只要比较一下他们首字母就知道了,按26个字母顺序R排在M的后面)，所以会往”Martin”的后面找，即找到Page145,然后在比较一下”Rudd”和”Smith”,”Rudd”比”Smith”小，所以会往左边找即Page120,然后在Page120逐行扫描下来直到找到”Rudd”。

如果不建索引的话，SQL SERVER会从第一页开始按顺序每页逐行扫描过去，直到找到”Rudd”。显然如果对于一个百万行的表来说，效率是极其低下的，如果建了索引，非常快就能找到。

非聚簇索引：

(图B)

看图B，非聚簇索引的结构图。

聚簇索引和非聚簇索引的区别就是：聚簇索引的数据物理存储顺序和索引顺序一致的，也就是它的数据就是按顺序排下来的。非聚簇索引的数据存储是无序的，不按索引顺序排列。

从图B可以看到数据页里是无序的。那么它的索引是如何建立的呢？

再看图B，它是把这个索引列的数据复制了一份然后按顺序排下来，再建立索引。每行数据都有一个指针。

我们再来找”Rudd”.首先从索引页的根开始找，查找原理跟聚集索引是一样的。在索引页的Page61找到”Rudd”,它的指针是470501，然后在数据页的Page5找到470501，这个位置就是”Rudd”在数据库中的实际位置,这样就找到了”Rudd”。

好了,索引的基本工作原理就是这样，可能实际上要复杂些。

SQL SERVER索引优化系列之一：工作原理&聚簇索引|非聚簇索引

SQL SERVER索引优化系列之二：索引性能考虑

SQL SERVER索引优化系列之三：填充因子

本文链接

Hello!

2010-09-28T15:52:00Z

Hello!

本博可以使用http://www.1986z.com/ 访问到。

本文链接