云南网络营销顾问，网站运营顾问，网络营销人周信东

　　“你这都属于prd或者mrd了吧，我们这边都是做技术的没有做pm的！” 阅读全文…

WINDOWS2003服务器安全设置，教你打造完全的WEB服务器

>> 服务器要及时打上安全补丁，以免被溢出攻击。 阅读全文…

2002年第一次用POP3连接邮件服务器的时候把我几年的邮件全给下载并从服务器上删除了。搞得我头大了半年多，之后很长时间没敢再用客户端软件来连接邮箱。后来一直在寻找一种能够与邮箱同步管理的软件。总是找不到合适的。直到今天才发现是自己太土了。原来我们一直在使用的mail.qq.com就支持该功能的，加上它提供的FOXMAIL，我们可以像在浏览器里管理邮件一样轻松地管理我们的邮箱。最直观的体现就是：当我在本地看了一封邮件，服务器上的邮件也被标注为已读；当我在本地删除一封邮件，同步后服务器上的邮件也被删除。这比原POP3的服务有太多的改进了。

具体的可以参看:http://service.mail.qq.com/cgi-bin/help?subtype=1&&id=28&&no=331

下面是一些技术层面的介绍。

阅读全文…

非常实用的WEB编辑器，在某些需要用户进行评论，但又不希望他上传图片的地方即可使用该类型的编辑器，而且体积之小，令人爱不释手。
强烈推广非常实用的WEB编辑器 

点击下载： WEB编辑器

 就像人们无法把握未来会怎样一样。有些企业家敢去预见未来十年甚至十五的事情，但是李彦红这样的互联网精英却只敢预测未来三年的变化。就像当年最早上网的人申请到5位的QQ号多半都丢失了一样，谁也不知道未来的网络会发现到一个5位QQ号能卖几千块钱的地步的。。在WEB2.0

我们无法把握未来的Internet会变成Web 3.0, X.X还是什么，但是回顾昨天的历史，我们不难看见有些很有价值的设计和元素，它们是会永远铭记在我们这一代人的大脑中的。这也让我理解了为什么有些歌曲会是经典永远的经典， 一如昨天在朋友杜鹏程处听到的那些7几年8几年的老歌曲。

以下将与您一同回顾WEB2.0的经典：Firefox不仅由于出色的功能，从而可以与IE进行对抗，而且它的网站设计也漂亮得没话说，给人的感觉非常清新。

阅读全文…

前段时间天度网络公司里的几个客户，在把网站转到其它服务器上以后发现网站被频繁的攻击，虽然客户方的技术人员已经知道通过IIS进行查看，但是均无果。在这里我们给大家列出了IIS里的倒数第二位的参数：访问状态。他们会看到很多具有攻击性的URL于是就非常紧张，其实看到攻击性的参数URL不有紧张，还要关注一下服务器反回的状态码是什么，结合这两点再对URL参数进一步的分析：这里也提供一个方便实用的软件IISLOGiis日志分析

常见的 HTTP 状态代码及其原因
 200 – 成功。 此状态代码表示 IIS 已成功处理请求。 
 304 – 未修改。 客户端请求的文档已在其缓存中，文档自缓存以来尚未被修改过。客户端使用文档的缓存副本，而不从服务器下载文档。 
 401.1 – 登录失败。 登录尝试不成功，可能因为用户名或密码无效。 
 401.3 – 由于 ACL 对资源的限制而未获得授权。 这表示存在 NTFS 权限问题。即使您对试图访问的文件具备相应的权限，也可能发生此错误。例如，如果 IUSR 帐户无权访问 C:\Winnt\System32\Inetsrv 目录，您会看到这个错误。 有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
187506 INF IIS 4.0 的基础 NTFS 权限  
 403.1 – 执行访问被禁止。 下面是导致此错误信息的两个常见原因：  您没有足够的执行许可。例如，如果试图访问的 ASP 页所在的目录权限设为“无”，或者，试图执行的 CGI 脚本所在的目录权限为“只允许脚本”，将出现此错误信息。若要修改执行权限，请在 Microsoft 管理控制台 (MMC) 中右击目录，然后依次单击属性和目录选项卡，确保为试图访问的内容设置适当的执行权限。 
 您没有将试图执行的文件类型的脚本映射设置为识别所使用的谓词（例如，GET 或 POST）。若要验证这一点，请在 MMC 中右击目录，依次单击属性、目录选项卡和配置，然后验证相应文件类型的脚本映射是否设置为允许所使用的谓词。 
 
 403.2 – 读访问被禁止。验证是否已将 IIS 设置为允许对目录进行读访问。另外，如果您正在使用默认文件，请验证该文件是否存在。 有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
247677 错误信息：403.2 Forbidden:Read Access Forbidden（403.2 禁止访问：读访问被禁止）  
 403.3 – 写访问被禁止。 验证 IIS 权限和 NTFS 权限是否已设置以便向该目录授予写访问权。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
248072 错误信息：403.3 Forbidden:Write Access Forbidden（403.3 禁止访问：写访问被禁止）  
 403.4 – 要求 SSL。禁用要求安全通道选项，或使用 HTTPS 代替 HTTP 来访问该页面。如果没有安装证书的 Web 站点出现此错误，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
224389 错误信息：HTTP 错误 403、403.4、403.5 禁止访问：要求 SSL  
 403.5 – 要求 SSL 128。禁用要求 128 位加密选项，或使用支持 128 位加密的浏览器以查看该页面。如果没有安装证书的 Web 站点出现此错误，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
224389 错误信息：HTTP 错误 403、403.4、403.5 禁止访问：要求 SSL  
 403.6 – IP 地址被拒绝。您已把您的服务器配置为拒绝访问您目前的 IP 地址。 有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
248043 错误信息：403.6 – Forbidden:IP Address Rejected（403.6 – 不可用：IP 地址被拒绝）  
 403.7 – 要求客户端证书。您已把您的服务器配置为要求客户端身份验证证书，但您未安装有效的客户端证书。 有关其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
190004 错误 403.7 或“Connection to Server Could Not Be Established”（无法建立与服务器的连接） 
186812 PRB：错误信息：403.7 Forbidden:Client Certificate Required（403.7 禁止访问：要求客户端证书）  
 403.8 – 站点访问被拒绝。您已为您用来访问服务器的域设置了域名限制。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章： 
248032 错误信息：Forbidden:Site Access Denied 403.8（禁止访问：站点访问被拒绝 403.8） 
403.9 – 用户数过多。与该服务器连接的用户数量超过了您设置的连接限制。 有关如何更改此限制的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 
248074 错误信息：Access Forbidden:Too Many Users Are Connected 403.9（禁止访问：连接的用户太多 403.9） 
注意：Microsoft Windows 2000 Professional 和 Microsoft Windows XP Professional 自动设置了在 IIS 上最多 10 个连接的限制。您无法更改此限制。 
 403.12 – 拒绝访问映射表。 您要访问的页面要求提供客户端证书，但映射到您的客户端证书的用户 ID 已被拒绝访问该文件。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 
248075 错误信息：HTTP 403.12 – Access Forbidden:Mapper Denied Access（HTTP 403.12 – 禁止访问：映射表拒绝访问）  
 404 – 未找到。 发生此错误的原因是您试图访问的文件已被移走或删除。如果在安装 URLScan 工具之后，试图访问带有有限扩展名的文件，也会发生此错误。这种情况下，该请求的日志文件项中将出现“Rejected by URLScan”的字样。 
 500 – 内部服务器错误。 很多服务器端的错误都可能导致该错误信息。事件查看器日志包含更详细的错误原因。此外，您可以禁用友好 HTTP 错误信息以便收到详细的错误说明。 有关如何禁用友好 HTTP 错误信息的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 
294807 如何在服务器端禁用 Internet Explorer 5 的“显示友好 HTTP 错误信息”功能  
 500.12 – 应用程序正在重新启动。 这表示您在 IIS 重新启动应用程序的过程中试图加载 ASP 页。刷新页面后，此信息即会消失。如果刷新页面后，此信息再次出现，可能是防病毒软件正在扫描 Global.asa 文件。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 
248013 错误信息：HTTP Error 500-12 Application Restarting（HTTP 错误 500-12 应用程序正在重新启动）  
 500-100.ASP – ASP 错误。 如果试图加载的 ASP 页中含有错误代码，将出现此错误信息。若要获得更确切的错误信息，请禁用友好 HTTP 错误信息。默认情况下，只会在默认 Web 站点上启用此错误信息。有关如何在非默认的 Web 站点上看到此错误信息的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 
261200 显示 HTTP 500 错误信息，而不显示 500-100.asp 的 ASP 错误信息  
 502 – 网关错误。 如果试图运行的 CGI 脚本不返回有效的 HTTP 标头集，将出现此错误信息。

        今天在优化网站博客的时候处理到一个小的细节：单个页面的title标题是这样的顺序：<title><?php bloginfo(‘name’); ?> <?php if ( is_single() ) { ?> &raquo; Blog Archive <?php } ?> <?php wp_title(); ?></title>。很明显，网站名称排在了最前面，这不是我们想要的效果，因此我们要把该本篇文章的真实标题放到页面的最前面，起到优化搜索引擎（SEO）的作用。但是当把wp_title()调到最前面并去掉blog archive相当字样后，一直有一个字符“>>”存在，觉得应该是在wp_title()函数里面的于是查找wp_title()函数，解决方法如下：

         其实是细心的网友可能已经发现是wp_title() 这个函数的处理的问题，所以就要找到这个函数的位置，由于wordpress版本不同，其库函数的存储方式也不同，也就是文件的命名方式变更了，所以网友还是要花费一定的时间去找这个函数的位置。

        本站的博客是2.7版本的WP，wp_title() 这个函数存储的位置是在wp-includes/general-template.php这个文件中，而其他版本的可能是wp-includes/template-funciton-general.php，并且找到wp_title函数中的“$sep = ‘»’” 改为 “$sep = ‘’”然后存储。

表示层：负责直接跟用户进行交互，一般也就是指我们的前台，用于数据录入，数据显示等。它不应该做太多的工作。表示嘛，也就意味着只做与外观显示相关的工作。不属于他的工作他不用管也不该管。
业务逻辑层：用于做一些有效性验证的工作。以更好的保证程序运行的健壮性。如数据的有效性判断。不允许为的地方是否输入了空字符串，该输入Email的，格式是否正确等，数据类型的合法性判断，该是整型的地方当然不能接受字符串了，数据库操作是否合法，如字段长度的有效性判断。sql防注入的问题，用户的权限的合法性判断等，通过以上的诸多判断以决定是否将操作继续向后传递。尽量保证程序的正常运行
数据访问层：顾名思义，就是用于专门跟数据库进行交互。对数据的添加，删除，修改，显示等。需要强调的是所有的数据对象只在这一层被引用，如System.Data。SqlClient等，除数据层之外的任何地方都不应该出现这样的应用。
ASP.NET可以使用.NET平台快速方便的部署三层架构。ASP.NET革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#,VB,J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名控件可以方便的使用自己定义的组件。显示层放在ASPX页面中，数据库操作和逻辑层用组件来实现，这样就很方便的实现了三层架构。
。
b)          为什么使用三层
那么我们为什么要使用分层开发呢，它有什么独特的优势呢？

      .NET开发平台为我们做开发提供了强大的技术支持，使我们的开发变得非常便捷，高效。通过code behind的强大支持，我们可以将页面设计和代码设计有效的分离，代码编写，页面设计同时进行。这比古老的asp那种插入式编写要迅速多了，Html归aspx，代码归aspx.cs，看起来倒也蛮清晰的，也没发现有什么不妥的地方
的确，光从功能实现的基础来说我们已经做得很好了，尤其对于一个简单的应用来说，代码量不是很多的情况下，这种一层结构开发完全够用了，没有必要搞得那么复杂。但是对一个复杂的大型系统来说这样的设计的缺陷就很严重了(下面会具体介绍，分层开发其实也是为大型系统服务的),。在开发过程中我们会不停把代码到处复制，以实现一些相似的功能。同样的代码为什么要写那么多次？不但使程序变得冗长，更不利于维护，一个小小的修改或许会波及很多页面。稍微不留神就会导致异常的产生。使程序不能正常运行。最主要的面向对象的思想没有得到丝毫的体现，打着面向对象的幌子却依然走着面向过程的老路。

      意识到这样的问题，我开始将程序中一些公用的处理程序写成公共方法封装在类中，供其它程序调用。象一些功能型的代码集合，数据库操作，如同SqlHelper那样对数据操作进行合理封装，把sql语句，参数列表作为参数，在数据库操作过程中，只要传入相应的参数就可以完成特定的数据操作，这就是我一开始的数据访问层，再不用每次操作数据库时都写那些重复性的数据库操作代码。在新的应用开发中，数据访问层可以直接拿来用。面向对象的三大特性之一的封装性在这里得到了很好的体现。似乎找到了面向对象的感觉，代码量较以前有了很大的减少，而且修改的时候也比较方便。这下应该可以了吧？

       试问一下，如果有一天数据库供应商发生了变化，因为数据量的增加，数据库有access变成了sql server？这下麻烦大了，原来的数据访问层失效了，数据操作对象发生了变化，且页面中涉及数据对象的地方也要进行修改，因为原来可能会使用OleDbDataReader对象将数据传递给显示页面，现在都得换成SqlDataReader对象，sql和access支持的数据类型也不一致，在显示数据时进行的数据转换可能也要进行修改。由sql向access的转换所做的修改会更多。还有一种情况，因为某种需要，我们要把Web形式的项目改造成windows应用，这时牵涉的修改有多大呢？如果在你的aspx.cs中放了很多处理代码，或者还有一部分代码存在于aspx中呢windows应用中可没有aspx阿，是不是整个系统需要重新来做了？这都是设计不合理惹的祸。再者，就是分布式的情况，现在的设计也无法做到。也就意味着，以上的设计充其量只能算小打小闹。
不知道我的解释是否让你体会了到了一些一层开发模式下的缺陷了呢？你是否碰到过这样的情况呢？幸运的是，多层开发架构的出现很有效的解决了这样的问题。通过将程序架构进行合理的分层，将极大的提高程序的通用性。

      三层中，各个层之间的分工是很明确的，面向对象吗，就像一个公司中的部门一样，每个部门的分工是不一样的，是哪个部门的任务就有哪个部门完成，对应的，各个部门的维护工作也有各自完成且不会影响其它的部门，至少影响不是很大，否则就只能说明分层还不合理。各个层之间通过有效的协作来完成系统的高效运行。表示层就是用来做接受/显示数据的工作，它要通过与其它层的协作来完成用户的请求，在这一层不该放太多的代码。逻辑层就是用来做数据有效性判断的，前面已经说过了，数据层就是用来完成底层数据交互的。表示层就不该去实现逻辑层的功能，当然我们会在客户端对用户的输入做一些判断，但服务器端，验证还要做。用户完全可以绕过客户端验证不是吗？现在我们在看上面说的问题，数据库发生了改变，我们只需要修改数据访问层，其它的地方我们都不用去管，这里我倾向于借助自定义数据实体来负责层与层之间的数据交互，我们把数据填充到自定义实体中，使用自定义实体的好处请参考我上面的两篇关于自定义实体的介绍的文章。通过数据访问层来完全封装数据供应商，使数据访问层对其它层完全透明，这样将数据库改变带来的修改完全限定在数据访问层内。我们可以借助一些模式来设计一个通用的数据访问层，这样即使数据库发生改变，我们只要修改一下配置就可以轻松搞定。对于开发平台的改变也变得很容易，不管是windows还是web，变化的只是界面而已，也就是所谓的表示层，它的内核没有变，相当于我们重作一个壳。表示层的代码是很少的，所以修改是很有限的，其它两层也不要修改就可以迅速做到web程序向windows程序的过渡。
你体会到三层的优势了吗？当然多层设计还有很多优秀的地方，我只是介绍了其中的一小部分。下面引入我所理解的三层的概念。
c)          我的三层结构。
那么怎么才能写出一个比较好的三层结构呢？下面说说我在程序设计中采用的做法，当然这里谈的只是我对三层的理解，不一定准确。欢迎拍砖。呵呵
         程序设计追求的是代码的通用性，可移植性，可维护性、功能扩展。怎么才能做到这些呢？这需要我们大量的实践经验做支撑。对面向对象思想的深入了解才能做到。个人觉得优秀的多层结构的设计肯定要先精通模式设计，不过遗憾的是对模式设计研究好长一段时间，依然没能领略到它的精髓，研究模式设计真的很过瘾哦。

Web层：也就是表示层，它负责响应用户的请求，对于这一层越薄越好，一般不应该写太多代码，或者为了页面显示的需要做少量的代码。大量的处理工作都交给其它的层去完成。就好比传递员，只负责接受，并将请求向后传递，具体怎么做它不用管。

Common层：这里用来封装一些常用的功能性代码，主要用来为其它层服务的。还有存放一些自定义实体类型和自定义实体类型集合。用于各层次之间数据交互的载体。如User，UserCollection，关于自定义实体这里就不展开了，如果系统复杂的话这一层应该比较厚实，包括下面的BLL层也是如此。
BLL层：就是逻辑层，用来对数据进行有效性验证，牵涉到对敏感数据的操作都需要经过这里做判断，然后才能决定操作是否合法。

Dal层：数据访问层；封装对数据库的操作。我们可以做一个通用的数据访问层，下次开发的时候，就可以直接拿过来用。很爽的。有一点从这里传进来、传出去的数据都用自定义实体代替，这样就可以实现数据访问层对其它层的完全透明。这里封装所有于数据库相关的代码，包括sql语句，存储过程等。

分层的思路说完了，在多人开发系统的过程中，就可以按层来划分任务，只要设计的时候把接口定义好，开发人员就可以同时开发。而且不会发生冲突，做前台的人根本就不需要知道数据库结构是什么，该怎么去查找，更新，删除数据，他直观调用响应的方法就可以了。数据访问层的人也不需要知道前台发生了什么，定义好与其它层交互的接口，规定好参数就行。各个层都一样，做好自己的工作就可以了，只要能做到对其它层的完全透明。这样就可以将修改限定在一个比较小的范围内。

但各个层具体的代码该怎么组织，我想这就要看个人的造诣了，要开发出高性能，可扩展的代码就需要结合模式设计的思想，通过代码结构的科学、合理的设计方能在日后的维护过程中游刃有余。

三、      总结

1)        从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度

2)        三层架构可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。美国人曾利用分式计算解密，几个月就破解了据称永远都破不了的密码

3)        也是三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了