项目文档 - 艺风在线 - Power By CSZI.com

CSBlogV2.11问题收集与信息反馈专用-提供09年贺岁版下载地址

一线风 — 2008-12-31 9:38:44

您在使用CSBlogV2.11的过程中有什么问题请发表与此的评论中，我们会尽快的给予解决。

CSBlogV2.11的更新历史记录：http://max.cszi.com/Blog/565-1.aspx

1. 如果出现要求写权限的错误，请打开Everyone的读写权限。并且数据库的只读属性要去掉。

2009新年贺岁版－牛气冲天下载：

1. http://down.chinaz.com/soft/24379.htm

2. http://files.cnblogs.com/atwind/CSBlogV211-Preview1.rar

Q: 为什么新发表的Blog会出现重写错误?
A: 原因是读取不到评论的集合及分页信息,解决办法一是让所有角色都可以读取评论,二是在Blog.xslt(这个对应你的主题的Blog目录下)修改136行附近的原内容为:

第二种办法是解决的根本.

----------------------------------------------------------
热心网友建议及回复:

1.大图片应该能自适应最大页面框架，超出某个比例时，将显示最大宽幅的自适应显示器和浏览器的页面（有滚动条也行），不过这一点不太重要。
A: 这个可以在后面设定一个比较小的缩略图,而不是直接设为最大的.(因为大图对客户端的下载也是个问题.) 还有个办法就是CSS来控制,溢出时自动隐藏(Baidu 是这样的)

2.图片（附件）上传后，在编辑状态中后或者重新上传，对于指定的上传文件夹中无效的旧图片和附件，系统均应自动给与删除。
A: 这个将在下一版本上实现.

3.后台可以查看图片附件以及手动清理非有效链接附件（图片）。
A: 这个将在下一版本上实现.

4.标签总管理，应该可以删除或者修改。
A: 这个暂时记下

5.系统自动识别图片后，在相册中集中显示；或者单独开设相册（画册）栏目，以列表幻灯等多种模式显示。
A: 这个将在下一版本上实现.

6.图片上传有时有故障，上传不能成功，需要查找原因修正。
A: 下一版本改进

7.留言板不可用,不过我考虑外挂一个，因为也有很不错的小型留言板。
A: 下一版本的插件形式发布

8.用户中心不可用，这需要及早修复，因为会影响用户体验。
A: 因为现在基本上是本人,所以大多是直接在后台更改,下一版本中改进

9.用户Norton(Symantec）防火墙开启时，诸多功能都出现异常，比如回复，显示为未知错误，但在无验证码情况下，在显示错误的同时，能发布。发文章和图片上传则不行。
A:这个没有碰到过,回头我查一下.

10.后台给管理员在后台查看文章标题和所有评论的功能，可以随时总览文章以及评论，方便删除。目前前后台管理分离，分别授权。习惯上后台管理权限应该包括前台管理。但方便起见，增加对文章列表、评论列表、标签列表的管理即可。
A: 暂时记下

11.ReWrite重写，可否写成html的后缀？搜索引擎很喜欢。
A:Html后缀是直接要修改IIS的解析指向的,这个可以在IIS上自已改.已经实现

12.从百度搜索官方站点看，搜索到的内容部分，需要进行改进。目前在meta使用了优秀的调用前部分文章文字功能，但没有发挥作用。
A:我的SEO确实是凭感觉,回头好好看一下!

13.ACC数据库总保持在出现ldb打开的状态，我不懂，不知道是否是同程序代码有关？
A: 一直保持在打开状态是能为了更快速的响应数据读取与更新,可以在后台暂时关闭.

可伸缩性最佳实践：来自eBay的经验

一线风 — 2009-10-23 12:00:07

转自：http://www.infoq.com/cn/articles/ebay-scalability-best-practices

在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（10¹⁵或2⁵⁰）来计算——可伸缩性是生死交关的问题。

在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。

可伸缩性有很多侧面——事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验，本文总结了其中若干关键的最佳实践。可能很多最佳实践你会觉得似曾相识，也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。

最佳实践 #1：按功能分割

相关的功能部分应该合在一起，不相关的功能部分应该分割开来——不管你把它叫做SOA、功能分解还是工程秘诀。而且，不相关的功能之间耦合程度越松散，就越能灵活地独立伸缩其中的一部分。

在编码层次，我们无时不刻都在运用这条原则。JAR文件、包、Bundle等等，都是用来隔离和抽象功能的机制。

在应用层次，eBay将不同的功能划分成几个应用程序池。销售功能由一组应用服务器运行，投标功能由另一组负责，搜索又是另外一组服务器。我们把总共约16,000台应用服务器分成220个池。这样就可以根据某项功能的资源消耗，单独地伸缩其中一个池。我们也因此得以进一步隔离及合理化资源依赖关系 ——比如销售池只需要访问后台资源的一个相对较小的子集。

在数据库层次，我们也采取同样的做法。eBay没有无所不包的单一数据库，相反我们有一组数据库主机存放用户数据、一组存放商品数据、一组存放购买数据……总共1000个逻辑数据库分布在400台物理主机上。同样，这种做法让我们得以单独为某一类数据伸缩其数据库设施。

最佳实践 #2：水平切分

按功能分割对我们的帮助很大，但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦，单项功能的资源需求随着时间增长，仍然有可能超出单一系统的能力。我们常常提醒自己，“没有分割就没有伸缩”。在单项功能内部，我们需要能把工作负载分解成许多我们有能力驾驭的小单元，让每个单元都能维持良好的性能价格比。这就是水平分割出场的时候了。

在应用层次，由于eBay将各种交互都设计成无状态的，所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以任意选择应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。

数据库层次的问题比较有挑战性，原因是数据天生就是有状态的。我们会按照主要的访问路径对数据作水平分割（或称为“sharding”）。例如用户数据目前被分割到20台主机上，每台主机存放1/20的用户。随着用户数量的增长，以及每个用户的数据量增长，我们会增加更多的主机，将用户分散到更多的机器上去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同，我们分割数据的方案也不同：有些是对主键简单取模（ID尾数为1的放到第一台主机，尾数为二的放到下一台，以此类推），有些是按照ID的区间分割（1-1M、1-2M等等），有些用一个查找表，还有些是综合以上的策略。不过具体的分割方案如何，总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。

最佳实践 #3：避免分布式事务

看到这里，你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟，几乎任何有意义的操作都要更新一个以上的实体——立即就可以举出用户和商品的例子。正统的广为人知的答案是：建立跨资源的分布式事务，用两段式提交来保证要么所有资源全都更新，要么全都不更新。很不幸，这种悲观方案的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响，随着依赖的资源数量和客户数量的上升，这些指标都会以几何级数恶化。可用性亦受到限制，因为所有依赖的资源都必须就位。实用主义的答案是，对于不相关的系统，放宽对它们的跨系统事务的保证。

左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性，通常既无必要，也不现实。Inktomi的Eric Brewer十年前提出的CAP公理是这样说的：分布式系统的三项重要指标——一致性（Consistency）、可用性（Availability）和分区耐受性（Partition-tolerance）——在任意时刻，只有两项能同时成立。对于高流量的网站来说，我们必须选择分区耐受性，因为它是实现可伸缩的根本。对于24x7运行的网站，选择可用性也是理所当然的。于是只好放弃即时一致性（immediate consistency）。

在eBay，我们绝对不允许任何形式的客户端或者分布式事务——因此绝不需要两段式提交。在某些经过仔细定义的情形下，我们会将作用于同一个数据库的若干语句捆绑成单个事务性的操作。而对于绝大部分操作，单条语句是自动提交的。虽然我们故意放宽正统的ACID属性，以致不能在所有地方保证即时一致性，但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们也采用了一些技术来帮助系统达到最终的一致性（eventual consistency）：周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement batches）。具体选择哪种技术要根据特定用例对一致性的需求来决定。

对于架构师和系统的设计者来说，关键是要明白一致性并非“有”和“没有”的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低，一致性也同样可以量体裁衣，根据特定操作的需要而保证适当程度的一致性。

最佳实践 #4：用异步策略解耦程序

提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件A同步调用组件B，那么A和B就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各部分必须共同进退——要伸缩A必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑：如果A推出B，那么非B推出非A。也就是说，若B不可用，则A也不可用。如果反过来A和B的联系是异步的，不管是通过队列、多播消息、批处理还是什么其他手段，它们就可以分别地伸缩。而且，此时A和B的可用性特征是相互独立的——即使B受困或者死掉，A仍然能够继续前进。

整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过SEDA（分阶段的事件驱动架构，Staged Event-Driven Architecture）等技术实现异步性，同时保持一个易于理解的编程模型。组件之间也遵守同样的原则——尽可能避免同步带来的耦合。在多数情况下，两个组件在任何事件中都不会有直接的业务联系。在所有的层次，把过程分解为阶段（stages or phases），然后将它们异步地连接起来，这是伸缩的关键。

最佳实践 #5：将过程转变为异步的流

用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统，牺牲数据或执行的延迟时间（完成全部工作的实践）来换取用户的延迟时间（用户得到响应的时间）是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都应该属于后台活动。主要用例过程中常常有很多步骤可以进一部分解成异步运行。任何可以晚点再做的事情都应该晚点再做。

还有一个同等重要的方面认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施——即使在任务最重的那一天里任务最重的那一秒，设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流，基础设施就不需要按照峰值来配备，只需要满足平均负载。而且也不需要立即处理所有的请求，异步队列可以将处理任务分摊到较长的时间里，因而起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从异步处理中得益。

最佳实践 #6：虚拟化所有层次

虚拟化和抽象化无所不在，计算机科学里有一句老话：所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象，而许多现代语言所用的虚拟机又是对操作系统的抽象。对象-关系映射层抽象了数据库。负载均衡器和虚拟IP抽象了网络终端。当我们通过分割数据和程序来提高基础设施的可伸缩性，为各种分割增加额外的虚拟层次就成为重中之重。

在eBay，我们虚拟化了数据库。应用与逻辑数据库交互，逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的路由逻辑，路由逻辑会把特定的记录（如用户XYZ）分配到指定的分区。这两类抽象都是在我们自己开发的O/R层上实现的。这样虚拟化之后，我们的运营团队可以按需要在物理主机群上重新分配逻辑主机——分离、合并、移动——而完全不需要接触应用程序代码。

搜索引擎同样是虚拟化的。为了得到搜索结果，一个聚合器组件会在多个分区上执行并行的查询，但这个高度分割的搜索网格在客户看来只是单一的逻辑索引。

以上种种措施并不只是为了程序员的方便，运营上的灵活性也是一大动机。硬件和软件系统都会故障，请求需要重新路由。组件、机器、分区都会不时增减、移动。明智地运用虚拟化，可使高层的设施对以上变化难得糊涂，你也就有了腾挪的余地。虚拟化使基础设施的伸缩成为可能，因为它使伸缩变成可管理的。

最佳实践 #7：适当地使用缓存

最后要适当地使用缓存。这里给出的建议不一定普遍适用，因为缓存是否高效极大地依赖于用例的细节。说到底，要在存储约束、对可用性的需求、对陈旧数据的容忍程度等条件下最大化缓存的命中率，这才是一个高效的缓存系统的最终目标。经验证明，要平衡众多因素是极其困难的，即使暂时达到目标，情况也极可能随着时间而改变。

最适合缓存的是很少改变、以读为主的数据——比如元数据、配置信息和静态数据。在eBay，我们积极地缓存这种类型的数据，并且结合使用“推”和“ 拉”两种方法保持系统在一定程度上的更新同步。减少对相同数据的重复请求能达到非常显著的效果。频繁变更、读写兼有的数据很难有效地缓存。在eBay，我们大多有意识地回避这样的难题。我们一直不对请求间短暂存在的会话数据作任何缓存。也不在应用层缓存共享的业务对象，比如商品和用户数据。我们有意地牺牲缓存这些数据的潜在利益，换取可用性和正确性。在此必须指出，其他网站采取了不同的途径，作了不同的取舍，也同样取得了成功。

好东西也会过犹不及。为缓存分配的内存越多，能用来服务单个请求的内存就越少。应用层常常有内存不足的压力，因此这是非常现实的权衡。更重要的一点，当你开始依赖于缓存，那么主要系统就只需要满足缓存未命中时的处理要求，自然而然你就会想到可以削减主要系统。但当你这样做之后，系统就完全离不开缓存了。现在主要系统没办法直接应付全部流量，也就是说网站的可用性取决于缓存能否100%正常运行——潜在的危局。哪怕是例行的操作，比如重新配置缓存资源、把缓存移动到别的机器、冷启动缓存服务器，都有可能引发严重的问题。

做得好，缓存系统能让可伸缩性的曲线向下弯曲，也就是比线性增长还要好——后续请求从缓存中取数据比从主存储取数据成本低廉。反过来，缓存做得不好会引入相当多额外的经常耗费，也会妨碍到可用性。我还没见过哪个系统没机会让缓存大展拳脚的，关键是要根据具体情况找到适当缓存策略。

总结

可伸缩性有时候被叫做“非功能性需求”，言下之意是它与功能无关，也就比较不重要。这么说简直错到了极点。我的观点是，可伸缩性是功能的先决条件——优先级为0的需求，比一切需求的优先级都高。

希望以上最佳实践能对你有用，希望能帮助你从新的角度审视你的系统，无论其规模如何。

参考

关于作者

Randy Shoup是eBay的杰出架构师。从2004年起担任eBay搜索基础设施的主要架构师。在加入eBay之前，他是Tumbleweed Communications公司的总架构师，也曾在Oracle和Informatica担任多个软件开发和架构的职位。

他经常在业界的会议上讲授可伸缩性和架构模式。

阅读英文原文：Scalability Best Practices: Lessons from eBay

关于枚举类型转换的效率测试

一线风 — 2009-6-25 13:54:23

权限系统里要有一些枚举和Int之间的转换,现测试一下,看看情况.呵~ 情况还是不错的!

1000000次测试结果:
4 <第三代权限判断方法>
255
4 <第二代权限判断方法>
28 <第一代权限判断方法>

看来枚举与int之间的转换消耗可以忽略呀.

C#代码

void T14()
{
Stopwatch timer = new Stopwatch();
timer.Start();
TT1();
timer.Stop();
Response.Write(timer.ElapsedMilliseconds.ToString() + "\n
");
Stopwatch timer2 = new Stopwatch();
timer2.Start();
TT2();
timer2.Stop();
Response.Write(timer2.ElapsedMilliseconds.ToString() + "\n
");
Stopwatch timer3 = new Stopwatch();
timer3.Start();
TT3();
timer3.Stop();
Response.Write(timer3.ElapsedMilliseconds.ToString() + "\n
");
Stopwatch timer4 = new Stopwatch();
timer4.Start();
TT4();
timer4.Stop();
Response.Write(timer4.ElapsedMilliseconds.ToString() + "\n
");
}
void TT1()
{
bool t = false;
for (int i = 0; i < 1000000; i++)
{
t = ((int)ManagePowerType.CategoryManage & (int) ManagePowerType.UserGroupManage) == (int) ManagePowerType.UserGroupChange;
}
}
void TT2()
{
ArrayList list = new ArrayList();
for (int i = 0; i < 1000000; i++)
{
list.Add(i);
}
}
void TT3()
{
bool t = false;
for (int i = 0; i < 1000000; i++)
{
t = (ManagePowerType.CategoryManage & ManagePowerType.UserGroupManage) == ManagePowerType.UserGroupChange;
}
}
class Test { int t = 1; public int T { get { return t; } } }
void TT4()
{
bool t = false;
for (int i = 0; i < 1000000; i++)
{
t = "IAMINT".IndexOf('A') > 0;
}
}

权限设计中的"依赖颠倒"

一线风 — 2009-6-8 13:49:29

一直在想，可是进度不是很尽人意呀．
目前的想法是：
1.　具体模块的权限设定写在配置文件里．通过类似于反射或是反序列化来映射到不同的模块上（可动太增加，这样多少插件来了也不怕）
2.　权限验证要灵活，不能像现在这样写死在方法里了（典型的面向过程编程呀）．初步想到可能要用到工厂方法模式［目前本人这方面欠缺，正在学习中］

-----------无奈的分割线---------------

今天[2009-6-8]想到,为什么我们要把权限绑定到角色上呢? 如果反过来呢? 比如某一方法(或是模块)用的权限,我给一个资源Id(Gid) 然后将这个Gid和角色映射起来(应该也能用到OO里面的重载来实现)! 这样,新的模块出来了,只需要分配新的Gid和新的角色映射即可,而不是再预先想到某些模块可能用到什么权限.

可能说的不是很清楚,不过大家有什么好点子,欢迎提出来呀!

再一次被编码折腾!

一线风 — 2009-4-21 17:22:06

Xhtml设计文档采用的是UTF-8编码,而Js则是直接创建的文本文件(默认ANSI)编码的. 结果折腾了好久,老是在IE下提示有一行缺少"}" ,而在FF下是正常的. 把Js编码改为UTF-8 结果正常. 哎~~~ 折腾.

Jquery小插件,根据css名称自动绑定相关事件.

一线风 — 2009-4-20 14:33:35

CSCMS正式开工了, 里面有用到样式的切换,看到动网的办法是直接写的javascript, 因为最近看了一下JQuery发现真的是小巧精悍,比较喜欢.就用上了.先放出来,嘿嘿,最学乍练的.有啥不对的提出来.

jquery.formStyle.js

/**
* author : atwind
* url : http://max.cszi.com
* use : $(function(){$(".objClassName").formStyle({className:"button_on"});};
**/
$.fn.formStyle = function(options) {
var settings = {
version : '0.10',
onEvent : 'hover', //focus,blur,hover is default
className : '' //事件发生时切换的样式
};
if(options) {
$.extend(settings, options);
}
var eStyle = settings['onEvent'] ;
if(eStyle == 'hover')
this.hover(function(){$(this).addClass(settings['className']);},function(){$(this).removeClass(settings['className']);});
if(eStyle == 'focus')
this.bind(function(){$(this).addClass(settings['className']);});
if(eStyle == 'blur')
this.bind(function(){$(this).removeClass(settings['className']);});
};

用Jquery实选Checkbox的全部选中和按样式类名分组选中

一线风 — 2009-3-5 15:18:34

还是权限部分的东东,因为要一个个的手选实在是太麻烦了,为什么不用JQuery呢?

JavaScript代码

"javascript" type="text/javascript" src="/Scripts/jquery-1.2.6.pack.js" >
"text/javascript">

在XSLT中的XPath表达式用使用变量

一线风 — 2009-3-5 11:56:04

这几天在写权限的时候,使用Xslt的转换过程中,因为要在Xpath表达式中用使用变量来进行路径筛选,想当然用的使用 ($Name是在循环中已经获取值的变量) 当然,出错了.

网上查了一下,好像也没有这种类似的选择, 准备用choose来手动写的时候,早上问了一下slightboy,结果问题就解决了,嘿嘿~~~ $Permission/*[name()=$Name](这种是查找出Permission下一级的名字为变量$Name的) , $Permission/@*[name()=$name] (这种是查找出Permission下一级属性的名字为变量$Name的) 嘿嘿,简单的循环就搞定一大片.

plus:这些天真是郁闷,天天下雨,最近还晚上下雨,我的鞋子呀,已经一个多月了,还是湿的,昨天晚上还把被单给都淋湿了.哎~~~~

关于.Net架构中对象的分类

一线风 — 2009-3-2 11:18:52

对象定义
数据对象（Data Object)
数据存储对象（Data Access Object）
业务对象（Biz Object)
业务对象工厂（Object Factory)
共用逻辑对象（CommonLogic Object)
应用对象（Application Object）

结果对象（ResultObject）

数据对象（Data Object)
数据对象基本是 Data Entity 在 application 里的表现方法。大体来说，每一个数据库的主要表都会有一个对应的数据对象。数据对象本身没有method，所以他的功能和 C 的structure 差不多。数据的来源可能是数据库表， XML 文档，或是 file 理的资料

数据存储对象（Data Access Object）
数据存储对象基本上是一些 method 来处理对应的数据对象。入股数据对象的数据来源是数据库的表。Data Access Object

业务对象（Biz Object)
业务对象是在（Business Logic Tier) 里，它的主要功能是将一个数据对象(或是一个数据对象集合）和相关的业务逻辑"包"起来以方便于应用对象的处理。Biz Object 所含的 Data Object 应该是 private （Data Object 是 Biz Object 的一个 Member Attribute，而所有的行为（Behavior）都应该经过 Method 来处理。另外，Biz Object 本身是不产生输出的结果给 Presentation(展示) 层的，但是它可以把自身的资料给传入Result Object。除了业务对象自身的逻辑，业务对象本身也会负责对数据库的操作，但是业务对象并不会自行 instantiate （实例），此类的功能需要依赖业务对象工厂。一个业务对象对于本身所含的是一个数据对象或是一个数据对象集合，处理逻辑和方法可能会不一样。
一个处理数据对象的业务对象在取名时用单数，一个处理数据对象集合的业务对象在取名时用复数。

每一个业务对象可以有一个DefaultOutput 方法（method），他是把自身实体的一些数据和一些算出来的数据给传入ResultObject 里。祥情请看Result Object。

业务对象工厂（Object Factory)
业务对象工厂是在（Business Logic Tier）里被应用，它的主要功能是产生一个空的业务对象或是从数据库里产生一个新的业务对象。有讨论把所有的数据的操作放在业务对象工厂里，这样每一个对象的工作可以分的更仔细。如果需要，我们以后会在这儿做调整。
共用逻辑对象（CommonLogic Object)
共用罗辑对象应该是在（Buisness Logic Tier) 里被应用的。它的应用是当一个逻辑需要两个或是两个以上 Biz Object 时而产生结果的，而且这个逻辑会被不同的用例而使用。

应用对象（Application Object）
应用对象是在（Business Logic Tier) 里。它的主要工能如下
接受页面层的请求和理解（interpret）请求的参数
掉动和instantiate（实例化）业务对象
处理业务逻辑
可以调动共有罗辑对象
产生输出和把输出的结果放入Result Obj

结果对象（ResultObject）
Result Object 是一个‘一般对象’。对于表现层的请求，业务逻辑层返回的是一个统一的 Result Object，而Result Object 的内容是自定对象，负责表现层和业务层的开发人员要事先只到里面的定义是什么. ResultObject? 可以比喻为一个XML 的文档。基本上他只是用来把资料从Business Tier (业务层)带到 Presentation Tier(表现层) 的， A data carrier （数据传输工具）。他可以运输一个或是多个业务对象的资料。
Result Object 本身并没有自己的Method。他可以被应用于对象或是业务对象操作。

转自:http://www.cnblogs.com/putishu/archive/2009/03/01/1400969.html

刚才在CNBlogs上看到的, 有时发现发布是个比较头痛的事情,嘿嘿,感觉还要进一步的整理.

C#:隐式转换,显示转换在CSWave.CSBlog中的应用.

一线风 — 2009-2-26 14:44:12

在CSBlog中的配置文件里,保存的是序列化后的Xml文档格式的信息,这种方式的好处是意义明确,易于扩展,并且不需要不停的修改数据库的字段.只要改变了程序,就能自动的进行升级.

在XML文档与对象的互相转换过程是,CSBlogV2.11以前的版本都是在方法里手动处理的,这样做不利于复用并且也比较容易出错,所以在今后的版本中,所有的要序列化成XML数据保存的对象都继承一个XmlComponentBase类.

XmlComponentBase

public abstract class XmlComponentBase
{
#region 与String类型的互相转换
///
/// 转换为标准的Xml文档
///
///
public string ToXml()
{
return Serializer.XmlSerializerToXml(this);
}
///
/// 序列化成Xml的文本片断
///
///
public override string ToString()
{
return Serializer.XmlSerializerToText(this);
}
#endregion
}

此类有两个方法,一个是ToXml()生成标准的XML文档保存至数据库,ToString()方法是生成Xml的片断,以挂接在要输出的进行转换的XML中.

然后在具体的对象类里增加两个方法:

C#代码

#region 显隐式转换
///
/// 显示将字符串转换为对象
///
///
///
public static explicit operator Statistic(string value)
{
if (String.IsNullOrEmpty(value))
return new Statistic();
return (Statistic)Serializer.XmlDeserializerFormText(typeof(Statistic), value);
}
///
/// 隐式将对象本身转为Xml文档
///
///
///
public static implicit operator String(Statistic value)
{
return Serializer.XmlSerializerToXml(value);
}
#endregion

这样对象与String之间的转换就方便得多,复用性也得到了提高.

-------------------------------------------------------

显隐式转换的语法如下:

operator

operator 关键字用于在类或结构声明中声明运算符。运算符声明可以采用下列四种形式之一：

public static result-type operator unary-operator ( op-type operand )

public static result-type operator binary-operator (
    op-type operand,
    op-type2 operand2
    )

public static implicit operator conv-type-out ( conv-type-in operand )

public static explicit operator conv-type-out ( conv-type-in operand )

参数：

result-type 运算符的结果类型。
unary-operator 下列运算符之一：+ - ! ~ ++ — true false
op-type 第一个（或唯一一个）参数的类型。
operand 第一个（或唯一一个）参数的名称。
binary-operator 其中一个：+ - * / % & | ^ << >> == != > < >= <=
op-type2 第二个参数的类型。
operand2 第二个参数的名称。
conv-type-out 类型转换运算符的目标类型。
conv-type-in 类型转换运算符的输入类型。

注意：

前两种形式声明了用户定义的重载内置运算符的运算符。并非所有内置运算符都可以被重载（请参见可重载的运算符）。op-type 和 op-type2 中至少有一个必须是封闭类型（即运算符所属的类型，或理解为自定义的类型）。例如，这将防止重定义整数加法运算符。
后两种形式声明了转换运算符。conv-type-in 和 conv-type-out 中正好有一个必须是封闭类型（即，转换运算符只能从它的封闭类型转换为其他某个类型，或从其他某个类型转换为它的封闭类型）。
运算符只能采用值参数，不能采用 ref 或 out 参数。
C# 要求成对重载比较运算符。如果重载了==，则也必须重载!=，否则产生编译错误。同时，比较运算符必须返回bool类型的值，这是与其他算术运算符的根本区别。
C# 不允许重载=运算符，但如果重载例如+运算符，编译器会自动使用+运算符的重载来执行+=运算符的操作。
运算符重载的其实就是函数重载。首先通过指定的运算表达式调用对应的运算符函数，然后再将运算对象转化为运算符函数的实参，接着根据实参的类型来确定需要调用的函数的重载，这个过程是由编译器完成。
任何运算符声明的前面都可以有一个可选的属性（C# 编程指南）列表。

explicit

explicit 关键字用于声明必须使用强制转换来调用的用户定义的类型转换运算符。

static explicit operator target_type { source_type identifier }

参数：

target_type 目标类型
source_type 源类型。
identifier Something。

注意：

转换运算符将源类型转换为目标类型。源类型提供转换运算符。与隐式转换不同，必须通过强制转换的方式来调用显式转换运算符。如果转换操作可能导致异常或丢失信息，则应将其标记为 explicit。这可以防止编译器无提示地调用可能产生无法预见后果的转换操作。

implicit

implicit 关键字用于声明隐式的用户定义类型转换运算符。

static implicit operator target_type { source_type identifier }

注意：

隐式转换可以通过消除不必要的类型转换来提高源代码的可读性。但是，因为可以在程序员未指定的情况下发生隐式转换，因此必须注意防止令人不愉快的后果。一般情况下，隐式转换运算符应当从不引发异常并且从不丢失信息，以便可以在程序员不知晓的情况下安全使用它们。如果转换运算符不能满足那些条件，则应将其标记为 explicit。

权限的设计思路

一线风 — 2009-2-5 15:46:41

目前CSBlogV2里的权限，是由角色里的一个属性来判断具体的功能模块的开放和禁止权限。但是这样的设计是非常错误的。因为功能模块可能会不同的增加和修改。

那么如何设计出扩展性能好，优秀实用的权限判断呢？想一想Windows系统里对每个文件夹的权限设定，他是针对角色来的，而不是由色来判断功能，而是由功能来开放和禁止角色的相关操作。

下一步的重大改进，角色权限判断的重新设计。

CSBlog主题与皮肤的制作与定制简单介绍

一线风 — 2009-1-4 9:35:01

先说简单的，皮肤(Style)：
制作皮肤是比较简单的，只需要找到/App_Themes/Theme/Style/Skin.css　然后更改CSS里的内容就OK了．至少要对CSS有一定的了解．可以下个CSS样式手册自已看看．CSS里面的应用到区块上样式我都做了注解了．

然后就是比较高级点的，你可能想自已增加样式应用到某些地方，或是对显示的结构进行更改，比如下面拉动的改成左右拉动．甚至直接用Flash来渲染．　这时候仅是修改CSS是无论如何也做不到的，那么只能修改主题了．

主题修改(xslt)：
修改主题其实就是修改xslt模板，xslt模板就是对xml原始数据进行渲染的．想查看输出的原始XML数据，只需要修改coreSettings.config里的 debug="true" renderOption="xml"　就会直接输出XML．

比如，有一个集合，它的路径是：CSWave.Xml/Blogs/Blog 我们想对其进行操作就只需要两步即可．
一，定义一个变理获取集合值：
二，渲染已经定义的变量：

XML/HTML代码

<xsl:for-each select="$Blogs">
<a href="/Blog/Blog.aspx?Id={@Id}"> <xsl:value-of select="@Title" /> a>
xsl:for-each>

这样就把Blog集合给列出来了．是不是超级简单呀？　通过上述的方法就能输出标准的自定的HTML各种结果．甚至可以修改直接输出XML让Flash读取数据来显示．

这样就能在不改动任何程序的源代码的情况下，做出你自已喜欢的不同的主题和样式．

总结：可以通过CSS直接更改同一个主题下的皮肤．但是不能更改网页显示的架构．所以如果想改变显示的架构，就只能改变主题．一般情况下只需改改样式就能得出漂亮的不同的风格的皮肤．

大家如果在制作皮肤的过程中有什么问题，欢迎提出！

2009年新年主题与皮肤的制作完成啦~

一线风 — 2009-1-4 9:29:41

从1号晚上21:30开始一直做到凌晨的4:10 一直在做这个2009年的皮肤，好在在前几天就从网上下到了2009年新相关的图片资源．对于背景的处理实在是不好搞，都差不多有三年没有好好的深入搞过CSS了，好多地方实在是想不到乍处理．晚上睡觉的时候梦到还有一个z-index可用，早上起来赶紧的试试．

又花了两个多小时才基本搞定，评论框里要是春倒在右边，背景也平铺就好了．不过呢，我想了一会儿也没有更好的办法．先这么来吧！

二踢脚在下面距左200px，上面要是有个烟花就更好了．不过现在没有．呵！回头找找．

FireFox对样式的大小写名称是敏感的即比较严格的，而IE则不是即IE的容错性比较好。

在电脑前面呆的时间太长了，现在眼睛好痛呀。一用眼镜看显示器就痛。先不搞了，看看JQuery。

欢迎转改，不过请注明一下原出处，谢谢！

CSBlogV2.11更新历史

一线风 — 2008-12-31 9:48:56

---2009-1-6---------------
1. 添加RSSLink到Html头里。可以在Maxthond里主动显示RSS地址。呵

----2009-1-5---------------
1. 重新更改一下2009皮肤；
2. 修正分类生成缓存文件时的排序；
3. 修正站点关闭时的联系方式；

----2009-1-4------------------
1. 在Blog编辑页增加一个防掉线的Ajax异步查询，防止长时间编辑Blog内容而意外退出。

----2009-1-3-----------------
1. Ajax服务项目开始

----2009-1-2-------------------
1. 新年样式图片切［搞到4.20了，好久没有搞美工方面的东东．花了5　6　个小时才把大体搞定，不行了．好困呀．先睡了！］
2. 完成新年皮肤样式；
3. 移除Static.config里的数据库名称配置，直接读以文件；
4. 更新为引用评论时不计引用字数，显示评论排行榜时只不显示引用内容，又引入了新的问题；

----2009-1-1--------------------
1. 修正可能出现的重复登录情况;
2. 样式名称规则与调整,参考LBSBlog样式；
3. 爱的滋味主题开始启用；

----2008-12-31------------------
1. 调整模板及样表;

----2008-12-29-------------------
1. 皮肤功能改为选择，配置文件放在/Config/Static.config里；
2. 新年皮肤开始制作，好汗！哈哈；

----2008-12-27--------------------
1. 修正配置相关备份还原与初始操作后的转向；
2. 移除暂时用不上的基本配置信息；
3. 调整分类排序，目前可支持2级分类，不过Blog被限制只能用一级分类:)；
4. 增加评论时可自动记住用户的呢称信息；

----2008-12-26---------------------
1. 搜索页的关键字及描述动态赋值[SEO]；

----2008-12-25-------------------
1. 将搜索页独立出来，避免职责不清；
2. 修正相关Blog的相样式问题；

----2008-12-24-------------------
1. 完成基本的URL重写。经简单测试，重写对执行时间消耗基本可以忽略．
2. 页面Title详细具体化．每一页要有一个不同的标题，分类第几页 . 搜索结果标题．[SEO优化]
3. 优化每页里的关键字，及内容描述.[SEO优化]

----2008-12-23--------------------
1. URL地址重写，汗，又重写？！这个是模板里的逆向重写功能啦，就是自动生成静态地址的。[URL重写时分组时数字查询串尽量用(\d+),纯目录模式下时可以用(.*),数字分页或分类不明的情况下可以用0代替，系统会自动识别]

----2008-12-11--------------------
1. 增加用户信息中心，可以查看自已的注册信息及最近登录日志；
2. 删除Google的广告，在UI.Library.xslt 可替换成自已的广告；

----2008-12-9-----------------------
1. 修正评论排行榜上引用的显示问题;

----2008-12-8-------------------------
1. 修正在ServerContent初始化之前抛出关闭站点异常的Bug;
2. 更新文件上传后的Js改写FCKEditor的Xslt操作代码;
3. 修正基本设定更新与模块设定更新混淆的Bug;
4. 全自动缩略图组,最大的缩略图做为原始图像,最小图像为缩略图;
5. 修正文件上传的权限判断的Bug；

----2008-12-4-----------升级为2.11版本-------------
1. 加入URL重写功能;
2. URL静态链接生成功能,在模板里自动生成静态链接,这个实在是太麻烦,暂时没有比较好的办法.

----2008-12-2------------------------
1. 修正RSS相关错误

----标准化(Xhtml)的CSBlog升级为CSBlogV2.10版本-------

----2008-11-27-------------------------
1. 修正模板定义的变量错误
2. 修正选择自定义的主题Bug

----2008-11-26--------------------------
1. 输出代码标准化为Xhtml

URL重写配置说明及模板逆向生成静态链接的相关说明

一线风 — 2008-12-25 16:03:36

/urlMapping.config 是重写的配置文件

true" 表示启用重写功能，false 时禁用重写功能

重写规则配置：
             url="/Blog/S-{0}-{1}.aspx"
         virtualUrl="~/Blog/S-(\d+)-(\d+).aspx"
         realUrl="~/Blog/Default.aspx?CategoryId=$1&Page=$2"
    />
url: 模板里逆向生成静态链接的字符串，{0}会被第一个参数自动替换掉，{1}会被第二个参数替换掉，以此类推。
virtualUrl: 重写后的路径，和url要对应。
realUrl: 真实路径,$1会自动替换成virtualUrl里的第一个参数，以此类推

模板里使用的例子：
--------------------------------

Blog列表：

Blog分类列表：第一个参数是分类Id号，第二个参数是起始页

Blog详细页：第一个参数是Blog的具体Id号，第二个参数是起始页

分页基础参数：第一个是分页的XML节点集，第二个是可能的参数（如首列表时为0，分类列表时为分类Id号，Blog评论分页时为Blog的Id）

RSS:只有一个分类Id的参数

注意此功能为CSBlogV2.11版本后才可使用。

快速把CSBlog里的内容给转到QQ空间里

一线风 — 2008-12-20 15:30:00

1. 打开你自已的QQ邮箱（没有的话只要有QQ就能开通本功能）

2. 点击QQ邮箱左侧最下面的 阅读空间

3. 最右侧最下面的 我的订阅 -> 添加

4. 在订阅输入框里填入你的Blog的Rss订阅地址，我的是：http://max.cszi.com/Blog/Feed.aspx (这个你可以在CSBlog系统的分类菜单左侧的订阅小图标上找到地址，如果要订阅全部就点首页左侧的那个小图标，然后复制地址)

5. 添加后就修改说明和确认页面了，确认订阅后开始阅读

6. 你可以在这儿直接阅读你的Blog原文的摘要，也可以打开一个具体的Blog,然后看看最下面，是不是有个转载到QQ空间的按钮？嘿，对就点这个，相信后面的我也不用多说了吧。

只有第一次使用才会填写订阅，以后就不用这么麻烦了，可以直接打开你的阅读空间，点开具体的Blog直接转载。这个功能不错吧？是不是也做个这样的功能集成到CSBlog呢？

Asp.Net里的XML+Xlst输出代码的标准化

一线风 — 2008-11-27 16:01:11

这两天一直在搞XML+Xslt输出的标准化,即输出Xhtml标准的代码

在.Net2.0的XslCompiledTransform 里名字空间 xmlns="http://www.w3.org/1999/xhtml" 是正确输出xhtml标准的关键
如果没有这个命名空间的话,输出的文档标签会自动去掉结尾的 / 符号即变成了

有两种角决的办法:
一,自定义一个XHtmlWrite类,重写一下WriteEndElement() 方法,自已判断那些情况要关闭;
二,就是在模板文件Xlst里加上上面的名字空间啦~ .

对于第一种方法,结果就是xslt模板里的所有
对于第二种方法就是输出的结果会自动合并空内容的标签,即

变成了

这个结果很是让人难受. 目前的解决办法是要么加要么是在不想关闭的标签尾加上 xml:space="preserve"> 并且把结束标签换行.

我不知微软是乍想的,从XslTransform改到XslCompiledTransform 结果就出来这么一个事.哎~

如果有哪位大侠有更好的解决办法,万望提醒一下 .

CSBlog主题制作(一)——将XML数据输出为其它格式(XHTML)

一线风 — 2008-11-24 17:32:25

先准备一个XML文件:

Link.xml

xml version="1.0" encoding="utf-8"?>
<Links>
<Link Name="Google" Url="http://www.google.com" />
<Link Name="LoveCherry" Url="http://www.cnblogs.com/lovecherry" />
<Link Name="CSDN.Net" Url="http://www.csdn.net" />
<Link Name="博客园" Url="http://www.cnblogs.com/" />
<Link Name="污染的Blog" Url="http://blog.csdn.net/wuhuiran" />
<Link Name="玩野网" Url="http://www.playes.net/" />
<Link Name="AJ：酒吧" Url="http://www.aj98.com/" />
<Link Name="才子：才子手记" Url="http://blog.54caizi.com/blog/" />
<Link Name="DLL：新的希望" Url="http://www.byval.org/" Title="这不过是一个测试而已" />
<Link Name="心灵：木鸟原创" Url="http://www.psder.com/" />
<Link Name="含笑修行's blog" Url="http://blog.knoweb.cn/" />
<Link Name="天擎科技" Url="http://www.69sea.com" />
<Link Name="黑妹博客" Url="http://blog.cnfol.com/xielina82782114" />
<Link Name="Devms论坛" Url="http://bbs.devms.com" LogoUrl="/Images/Links/dmfourm.jpg" Title="Asp.Net Commitury." />
Links>

再准备一个XSLT模板文件

T.xslt

xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>
<xsl:variable name="Links" select="/Links/Link" />
<xsl:output
method="xhtml"
version="1.0"
encoding="utf-8"
omit-xml-declaration="no"
indent="yes"
media-type="application/xhtml+xml"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
/>
<xsl:template match="/">
<xsl:call-template name="T.LinkPanel" />
xsl:template>
<xsl:template name="T.LinkPanel">
<div>
<ol>
<xsl:for-each select="$Links">
<li><xsl:value-of select="@Name" />li>
xsl:for-each>
ol>
div>
xsl:template>
xsl:stylesheet>

然后就是C#转换代码:

C#代码

XslCompiledTransform xsl = new XslCompiledTransform();
xsl.Load(@"C:\Web\T.xslt");
xsl.Transform(@"C:\Web\Links.xml", @"C:\Web\Link.html");

执行后的输出结果:

XML/HTML代码

xml version="1.0" encoding="utf-8"?>
>
<div>
<ol>
<li>Googleli>
<li>LoveCherryli>
<li>CSDN.Netli>
<li>博客园li>
<li>污染的Blogli>
<li>玩野网li>
<li>AJ：酒吧li>
<li>才子：才子手记li>
<li>DLL：新的希望li>
<li>心灵：木鸟原创li>
<li>含笑修行's blogli>
<li>天擎科技li>
<li>黑妹博客li>
<li>Devms论坛li>
ol>
div>

怎么样?是不是超简单呀? 呵~~~

待续...

CSBlogV2[2.0.1]更新历史一览表

一线风 — 2008-11-21 16:09:08

----2008-12-2------------------------
1. 修正RSS相关错误

----标准化(Xhtml)的CSBlog升级为CSBlogV2.10版本-------

CSBlogV2.01 版升级历史终结。

----2008-11-27-------------------------
1. 修正模板定义的变量错误
2. 修正选择自定义的主题Bug

----2008-11-26--------------------------
1. 输出代码标准化为Xhtml

----2008-11-24----CSBlogV2_B081124发布-----------------
1. 有的朋友反映放在Handler里的验证码验证码显不出不，现独立成单独的文件；
2. 修正配置更新时的表单值获取错误；
3. 修正评论引用时的乱码；

----2008-11-23----------------------
1. Blog公告改至Blog频道配置；
2. 取消默认主题的硬编码，由扩展的核心配置里读取；
3. 相关Blog最多条数为0时关闭相关Blog的显示；

----2008-11-22---------------------
1. 扩展配置,合理化配置.频道配置分离出基本配置;
2. 上传文件设定改至后台配置里更改,移去核心配置里的上传设定;
3. 自言自语改为从后台博客配置里更改,而不用从模板里更改;
4. 注册时更新用户统计数据，后台加入手动更新blog，评论及用户数量的手动更新;
5. Blog详细页面下增加相关Blog,(通过Tags关键字进行查询);
6. 增加相关文章的开启关闭功能，可人为选择是否显示;
7. 修正IP获取时可能为空的情况
8. 增加IP查询引擎，暂时为外部引擎。

----2008-11-21----------------------
1. 置顶日志自动隐藏，可由用户手动展开摘要;
2. 基本配置扩展开始[WebConfig];

----2008-11-20----CSBlogV2B081120发布-------
1. 自定义错误页面403,404,一般性错误;

----2008-11-18-----------------------------
1. 自定义扩展配置文件及相关代码;

----2008-11-17-------------------------
1. 修正修改已经存在的Blog后阅读统计归0的Bug;

----2008-11-13-------------------------
1. 修正发表日志时更新Blog排行榜的Bug;
2. 只有修改摘要或是修改内容才会附加修改信息;
3. 修正Tags选择时页面弹出的样式;

----2008-11-12----------------------
1. 修正评论榜选择评论的BUG,只显示公开的评论;
2. 后台增加可关闭Access库的文件链接功能;

----2008-11-11----------------------
1. 无限分类是个大麻烦,暂时先凑合着用吧,回头再来搞这个**
2. 显示的自动导航页的链接自动区别,有外部链接的直接显示,不通过site.aspx中转;
3. 分类自动生成XML文件缓存,通过频道自动生成;

----2008-11-8---------------------
1. 新增加一个Style属性(限制当前模块可以使用的最大限分类级数)到Chanel表上,但是显示的时候输出XML模式下一直请求,好像有问题 . 可能是有Channel这个词，使得总是从缓存频道里找;

----2008-11-07-------------------------------
1. 自动菜单功能;
2. 修正删除Blog没有删除对应的评论的BUG
3. 增加初始化当前配置,用以初始化被搞乱的配置;

----2008-11-06----------------------
1. 加入SitePage表，可动态增加相关静态页面;

----2008-11-05----------------------
1. 重写Blog/Edit.aspx页与Blog/Blog.aspx页相关函数,使其更加逻辑合理;
2. 增加评论相关的权限,可读,可发布.可删除;
3. 修正编辑Blog时的错误，及载入Blog、发表Blog、删除Blog时的相关更新;
4. 增加Blog删除功能;
5. 加入关于我们功能页面;

CSBlogV2内测与问题反馈.

一线风 — 2008-11-17 10:49:01

演示地址：http://csblog.cszi.com

技术特点说明:
----------------------------------------------------------------------------------
1. 分层架构设计
2. 采用XML输出+XSLT模板生成XHTML页面显示的方式，主题更改更容易，更方便。
3. 自定义的web.Config扩展，数据库连接更容易。

目前正在内测中,有需要的请发Email至:zhouyu@69sea.com进行索取,或是加入官方QQ群[24301472]索取.

今天把web.config的扩展配置给基本写完.修正了修改Blog时点击数归零的Bug