作者BLOG：
http://blog.csdn.net/btbtd/
废话少说, 至目前为止, 我觉得最快的显示数据查询语句:
<%
start=timer()
set rs=server.CreateObject("adodb.recordset")
with rs
.open "select top 50000 * from ctglossary",conn
set gname=rs("gname"):set subgname=rs("subgname")
do until .eof
response.write gname
response.write subgname
response.write "<br/>"
.movenext
loop
set gname=nothing:set subgname=nothing
.close
end with
set rs=nothing 'shawl.qiu code'
response.write "<p/>"&formatNumber((timer()-start)*1000,3)&"毫秒"
%> |
$cut$
以上语句执行情况为:
10000条记录: 375.000毫秒
50000条记录: 1,500.000毫秒
注意以上语句的 name=rs("field"), 前面都加了 set.
如果不加 set, 且在循环体以外, 那样显示的数据将会是许多条重复的记录.
---
如果循环体内使用的是 rs("filed") 而不是定义好的变量, 那样会降低效率, 至于为什么, 比如你输入 rs(0) 代替 varname 也是一样的效率, 道理就在这里.
注意循环体内没有使用拼接字符(&), 循环体外使用无关紧要.
至于为什么不使用 & 字符, 你输出十万个 response.write var(不加 &), 和输出一个 response.write var&var...&var10000 就知道.
至于还有哪些地方不要使用 & 字符, 除了循环体以外, 重复使用的地方都不要使用 & 字符, 比如 sub, function, class.
可能会有人说 obj.getString(parameter) 显示很快, obj.getRows() 也很快.
但我测试的结果是, 这两个传说不灵.
还有预存储可能也不错, 但由于没有需求, 这个没试过.
最后, 一个不错的思考, 难道你不考虑静态技术吗?
shawl.qiu
2006-8-12
http://blog.csdn.net/btbtd/archive/2006/08/12/1052702.aspx
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(90) |
评论 (0) |
编辑
㏒兽 23:11:26
就是数据库服务器放内网
㏒兽 23:11:43
web应用 服务器也放内网
㏒兽 23:11:58
外网搭建一个apache的proxy来访问内部
㏒兽 23:12:04
的web服务器
㏒兽 23:15:19
如果有防火墙就限制外网访问那台机子只能通过apache的proxy去读取
Kittow↑DIV 23:15:05
哦~~~
用squid也可以了？^_^
Kittow↑DIV 23:17:11
我的想法是
外网是一台web服务器，内网放另一个web和数据库
外网的机器通过1433端口访问内网的数据库，
但是这样做，外网还是可以直接查看到内网的机器，不安全
㏒兽 23:20:33
使用apache的porxy到内部读取页面这种方式应该比较稳当
㏒兽 23:25:51
就是相当于你访问apache,apache所在的服务器能访问内网把东西拿出来给你
Kittow↑DIV 23:26:34
有个问题
如果入侵了apache的那台服务器，不是就可以入侵内网了？
㏒兽 23:31:25
所以你就限制只有apache那台机的80能让外部访问,然后apache那台机制能访问内部的web服务器的80阿
㏒兽 23:32:59
你外部网访问的用户应该不多吧？
Kittow↑DIV 23:30:43
恩，其他的全部关闭？
21、139那些都可以关？
㏒兽 23:33:43
你不访问的都关闭当然就最安全了
Kittow↑DIV 23:31:26
不多，企业网站而以
主要是内部网站的访问
㏒兽 23:34:19
这种方法实际上就是apache那台机类似于一个外部客户端访问
Kittow↑DIV 23:31:59
恩，了解
这样说不定也可以做用户登录的操作？
㏒兽 23:35:08
肯定可以做登陆的
㏒兽 23:35:18
只要你把cache的相关参数调节好
Kittow↑DIV 23:32:34
我们都没有试过squid代理的论坛能不能用呢
估计可以，sohu和sina都可以
㏒兽 23:35:57
mop就是用的squid
Kittow↑DIV 23:33:49
厚厚~~~ squid真是价格便宜量又足
文档：(2)利用apache做Web Proxy
http://www.lslnet.com/linux/docs/linux-2750.htm
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(232) |
评论 (0) |
编辑
BLOG：http://blog.skyhe.com
(本文遵守“创作共用”协议，转载请注明作者和原文地址)
最近在用tsys 2.0做网站，发现官方系统在添加资源块时有个重大BUG：
无法使用自定义SQL！
按照作者的意思，应该是<parameter type="custome">就可以使用，但实际上不行
察看inc/SliceParser.class.asp后找到了问题：
修改办法：
1、195行左右
End If
loop_view_resource = strHtml
注释或删除End If
2、144行左右
'替换Sql
Sql = Replace(Sql, "$TOP$", pTop)
Sql = Replace(Sql, "$WHERE$", sqlWhere)
下面添加
'--- 支持自定义SQL的修改
End If
修改完成。
下面你就可以在添加资源碎片时使用自定义SQL了，享受强大的T-SQL魅力！~^_^
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(138) |
评论 (0) |
编辑
发表于《家用电脑与游戏机》2006年7月号，转载请注明出处
所谓Web Game翻译成中文就是“网页游戏”，是指无需下载和安装客户端程序、基于JAVA和ActiveX等技术通过浏览器来进行游戏的一种游戏形式。
Web Game的出现大致在上世纪90年代，介于MUD和大型MMO游戏之间。随着Web编程技术的普及发展，很多Web程序员在工作之余产生了制作Web Game的冲动（笔者也是其中之一哦），于是一款一款的Web Game就这样的诞生了。
Web Game的优劣
在网络游戏大行其道的今天，Web Game作为一种重要的游戏形式是如何生存和发展的呢？让我们来看看Web Game和大型网络游戏相比有那些优势和劣势。
Web Game的优势主要体现在它的方便性上，因为Web Game不需要下载客户端，主要处理的是游戏规则和软件算法，对网络带宽的要求相对较低，玩家几乎可以在任何时间任何地点任何一台能上网的电脑上快乐地游戏，不会受到其他客观条件的制约。
而Web Game的劣势也很明显，通常游戏方式简单，游戏流程较短，文字与图片搭配的画面与大型网游也无法相提并论。
尽管Web Game本身有着这样那样的缺点，但是还是有很多玩家沉浸其中，乐此不疲，这是因为Web Game本身的游戏趣味吸引了他们。Web Game是创意的舞台，Web Game不能在画面上取胜，只能在创意上下功夫，没有创意的Web Game是无人问津的。
Web Game之日本篇
已经很难考证最早的Web Game是哪一款，但日本的Web Game较早引起了人们的注意，这和日本游戏业的发达是有一定的必然联系的。日本的Web Game普遍采用CGI技术实现，游戏性和创意十足。其中最具有代表性的，当属大名鼎鼎的EBS（Endless Battle System，中文名为《无尽的战斗（或译为战争》），在其被汉化引入中国之后，培养了中国第一代的Web Game玩家。
由于CGI技术的局限性，导致日本的Web Game只能停留在同人游戏的阶段，无法同时容纳大量用户，且容易发生数据丢失。因为其出色的游戏性，所以虽然年代久远，至今仍然有很多玩家在玩日本的Web Game。笔者在这里推荐几款创意上佳的日本Web Game的汉化版。
●无尽的战斗
作为最早出现在中国的Web Game，至今仍然魅力不减。《无尽的战斗》的游戏特色在于这里没有NPC，只有玩家间的互动。玩家必须和其他玩家不断的战斗来提升自己，而作为失败的惩罚，被击败的玩家将被限制行动一段时间，是一款把PK二字发挥到极致的Web Game。
游戏地址：
http://www.coolsee.com/cgi-bin/ebs129/ebs.cgi
●商人物语
和《无尽的战争》不同，《商人物语》的主题不是战斗，而是经营。在这里，“钱”才是王道。玩家需要收集大量的货物放进自己的小店，这样资金就会不断的增长。当然如果想成为商人中的佼佼者，光靠卖普通的货物永远不会发家。这就需要玩家不断提升自己的实力，或者养龙，或者写书，或者孵蛋，只有高级的货物才能卖更多的钱。什么？要问钱多了有什么用？呵呵，玩一下就知道了。
游戏地址：
http://www.webgame.com.cn/drago
●玫瑰战争
《玫瑰战争》（The Wars of Roses）的汉化版名为《雷姆力亚年代记》。虽然玩家扮演的只是一个角色，游戏的进行方式也是RPG的方式，但是游戏中国家之间的斗争才是永恒的主题。国家之间的利益争夺，严酷的政治制度，在游戏中随处可见，这是一款把战略和角色扮演的游戏方式结合得相当出色的Web Game。
游戏地址：
http://pocketrose.gameside.net/
Web Game之欧美篇
欧美的Web Game曾经以休闲游戏为主，但是近年来进步迅速，并且有逐渐发展壮大的趋势。和日本的Web Game相比，欧美出品的Web Game在题材、技术手段和游戏方式上都有很大的不同。
首先，在技术手段上，欧美的Web Game采用了比较新的WEB编程技术如ASP/PHP，很好地解决了日式Web Game不能容纳大量用户和丢失数据的问题。其次，在游戏题材的选择上，是以战争、科幻题材为主，这恐怕和欧美玩家的游戏口味有关吧。
总体说来，欧美的Web Game可以算是第二代的Web Game，在技术、画面和游戏深度上都比日本的Web Game高出不少。可以认为欧美的Web Game带动了Web Game发展的第二次浪潮。
●Ogame
欧美Web Game的代表作Ogame出自德国，是国内玩家最熟悉的Web Game之一。在Ogame的世界中，玩家是一个星球的主人，依靠最初的资源，通过研究发展科技，不断的增强自己的经济和军事实力。实力足够之后，玩家可以选择向其他星球发动战争，也可以与其他玩家进行贸易交流。游戏的进行方式为即时制，浩瀚的宇宙，绚丽的星球，人与人的高度交互，是这款Web Game吸引了大量玩家的主要原因。
目前Ogame在全世界范围内开设了多种语言版本的网站和服务器，拥有广大的玩家群，2006年1月其英文站（www.ogame.org）的用户数量突破10万。不少爱好者还为其建立了专门的研究站点。笔者向大家推荐银河帝国资料站（www.ogamecn.com），上面有大量的Ogame相关游戏资料和五个中文Ogame服务器的地址，而下面这个简体中文域名实际指向的是繁体版Ogame。
游戏地址：
http://www.ogame.com.cn
●Advance Wars By Web
这是一款根据GBA上的人气游戏《高级战争》改编的Web Game。游戏规则和GBA上的《高级战争》一般无二，所不同的是，这里的对手是实实在在的真人玩家。《高级战争》是一款优秀的游戏，它的网络版自然也不会逊色，笔者向大家特别推荐这款游戏。
游戏地址：
http://awbw.amarriner.com
●Adventure Quest
这是一款诞生于2002年的美国Web Game，游戏的前端界面采用Flash制作，所以和传统的Web Game相比，画面效果不俗。游戏是采用回合制战斗的正统RPG，创意上虽然有些平庸保守，但确实是Web Game中的优秀作品。想体验下Flash版RPG的玩家可以一试。
游戏地址：
http://www.battleon.com
●Travian
类似《帝国时代》的战略游戏，玩家可以从罗马、高卢和条顿3个民族中选择其一，开始自己的建设与征战之途。游戏人气颇高，但目前没有中文版，推荐英语好的玩家尝试。
游戏地址：
http://www.travian.com
●尼奥宠物
始于1999年的尼奥宠物网全球注册用户达到了惊人的7000万，是最大的虚拟宠物网站。它在2005年被维亚康姆以1.6亿美元巨资收购，简体中文版现已面世。
游戏地址：
http://www.neopets.com
●哈宝
《哈宝》（Habbo Hotel）是一家芬兰公司2001年的作品，采用Shockwave插件直接通过浏览器进行游戏。这款全球最大的图形化虚拟社区游戏拥有4000万用户，今年由中信泰富旗下梦城互动娱乐公司引入国内。游戏自由度很高，像素化界面风格非常可爱。
游戏地址：
http://www.habbochina.com
Web Game之国产篇
国内Web Game的历史可以追溯到上世纪末，当时EBS等作品使一部分有条件的玩家充分领略了Web Game的魅力。但是由于第一代Web Game的局限性，在短暂的高潮过后，国内的Web Game进入了一个低谷期。经过漫长的黑夜之后，随着网络设备与技术的不断发展，国内的Web Game也开始慢慢壮大起来，并且由原来单纯汉化日本欧美作品的阶段发展到改编和原创Web Game的阶段，这不能不说是一种巨大的进步。
●战神世界
《战神世界》是由国内的几位Ogame爱好者开发出来的原创Web Game。游戏吸收了Ogame的特色和精华，并且加入游戏制作者自己的创新，使得《战神世界》一经推出就受到了广大Web Game爱好者的热烈欢迎。《战神世界》的游戏进行方式类似单机游戏《帝国时代》，玩家最初只有一个城市，通过不断的发展经济、兵力和科技，进行扩张、骚扰和进攻。游戏中的战斗、建设、移动都是真实时间制，这使得《战神世界》的游戏乐趣与单机RTS作品相比有过之而无不及。
游戏地址：
http://www.warlord.cn
●无尽的战争Ⅱ
前面提到了第一代Web Game的代表作是《无尽的战争》，这款《无尽的战争Ⅱ》则是在前作基础上的改良和发展。该游戏不但解决了一代无法容纳大量用户的问题，还对游戏的方式和内容进行了大量的修改和扩充，甚至说是一款全新的作品也不为过。
游戏地址：
http://www.iewan.com/ebs2
目前，国内的Web Game正向着欣欣向荣的方向发展，越来越多的玩家和业内人士把目光投向了这一领域。相信在今后一段时间内，会有更多更好玩的Web Game出现在大家面前，到时候笔者再给大家做汇报，再见！（最后插播广告：对Web Game制作感兴趣的读者请加QQ群：302532。广告完毕:-）
附：杂志扫描图
点击查看第一页
点击查看第二页
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(337) |
评论 (0) |
编辑
.NET构架之我见
http://community.csdn.net/Expert/topic/4950/4950034.xml?temp=.5647241
Castle 开发系列文章
http://terrylee.cnblogs.com/archive/2006/04/28/castl_ioc_article.html
Enterprise Library系列文章回顾与总结
http://www.cnblogs.com/Terrylee/archive/2006/08/01/enterprise_library.html
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(176) |
评论 (0) |
编辑
BLOG：http://blog.csdn.net/lubosun
先举一个曾经在哪本书上看到的例子：现在你想在1米宽的小溪上建一座桥，你会在上面放块木板就完了。如果想在宽一点的小河上建这桥，你就需要计算木材用料，价格等，如果需要别人帮忙，你还要多一些图纸什么的让别人理解你的想法。现在你要在大江上面建桥，你需要有整体的计划，包括各个方面，比如将来可能的收费和利益分配等问题。
这里讲3层式，其实是针对“大江上面建桥”来的，对于1米宽的小溪，在实际中可能一点用都没有。不过现在我不可能去拿个长江大桥作例子来讲，所以这里还是用这条简单的小溪，讲讲怎么建桥。之所以讲这么多废话，是为了防止部分人看完此文之后“小小一个东西，搞那么麻烦干什么。。”其实这里讲的不是具体的这个例子，而是分层的思想，理解这点非常重要。
下面我就我们大家日常见最多的例子来讲，就是“用户登录”的例子。这个例子很简单，但是麻雀虽小五脏俱全。从数据访问到业务规则到界面全有了。
本文分2个部分，如果只想研究面向对象的思想，对实现已经熟悉，可以跳过第一部分。
第一部分新建一个空白解决方案。然后：
“添加”－“新建项目”－“其他项目”－“企业级模版项目”－“C#生成块”－“数据访问”（数据层，下简称D层）
“添加”－“新建项目”－“其他项目”－“企业级模版项目”－“C#生成块”－“业务规则”（业务层，下简称C层）
“添加”－“新建项目”－“其他项目”－“企业级模版项目”－“C#生成块”－“Web用户界面”（界面层，下简称U层）
右键点“解决方案”－“项目依赖项”，设置U依赖于D、C，C依赖于D。
对U添加引用D、C，对C添加引用D。
到此为止，一个三层的架子建立起来了。我上面说的很具体很“傻瓜”，知道的人觉得我废话，其实我这段时间很强烈的感觉到非常多的人其实对这个简单的过程完全不了解。虽然不反对建2个“空项目”和1个“Asp net Web应用程序项目”也可以作为3层的框架，而且相当多的人认为其实这些“企业级模板项目”其实就是个空项目，这是一个误区。没错，企业级模板项目你从解决方案资源管理器里看它是个什么也没有的，但是你可以用记事本打开项目文件，看见不同了吧？？有些东西在背后，你是看不见的，不过系统已经做好了。也就是说，如果你在C层里的某个类里“using System Data SqlClineit”，或者使用一个SqlConnection对象，编译时候不会出错，但是会在“任务列表”里生成一些“策略警告”，警告你在C层里不要放应该放在D层的东西（虽然就程序来说没错，但是可读性可维护性就打了折扣）而这种功能，空项目是无法給你的。
我们知道建桥需要砖块，应该是先准备好砖再来建桥，不过为了讲解上的顺序性和连贯性，简单性。我们先建桥，建的过程中需要砖块再现做，这样就不会多出来“桥不需要的东西”。注意在实际中，还是应该先准备砖块。
U层其实就是桥，C层是砖块，D层是原料（石头、沙子）。这也解释前面为什么U层要引用、依赖D层（而不是U对C，C对D的层次），因为桥除了需要砖头，其实也需要石头沙子。
我们在U层建一个Login aspx（这里插入一句，我不喜欢去把系统自动生成的WebForm1 aspx拿来改成login或index或直接删除，我一般留着它当测试代码用，等到整个系统冻结再把它移除就可以了。）添加1个TextBox（id=txt），一个DropDownList（id=ddl），一个Button(id=btn)。其中DropDownList用来选择用户名，button是提交按钮， TextBox用来输入密码。
现在我们必须要添加的代码分为2部分： 1、Page_load时对ddl的初始化。2、btn的click处理。
1：
private void Page_Load(object sender, System.EventArgs e)
{
if(!IsPostBack)
{
this.ddl.DataSourse=DataManager.GetOneColunm(“User”,”uid”); //讲解1
this.ddl.DataBind();
}
}
2：
private void Btn_Click(object sender, System.EventArgs e)
{
string uid=this.ddl.SelectedValue;
string psw=this.txt.Text;
if(psw =””)
MessageBox(“空密码！”);
else
{
User theUser;
try
{
theUser=new User(uid); //讲解2
}
catch(Exception e)
{
MessageBox(e. Message);//讲解2
return;
}
if(theUser.CheckPsw(psw)) //讲解3
{
theUser.SetSessions();
Response.Redirect(“……………..”); //登录成功！
}
else
{
MessageBox(“密码错误！”);
}
}
}
讲解1：DataManager 是D层中的一个类，提供常见的数据操作。GetOneColunm(string Table,string Colunm)方法返回一个只有1列的DataTable，值为数据库中表名为Table，的Colunm列。
public class DataManager
{
public DataManager()
{
}
public static DataTable GetOneColunm(string Table,string Colunm)
{
//此处省略相关代码。返回指定表指定列
}
}
其实这个地方演示的是在U层直接绕过C层访问D层的例子，因为该结构逻辑上很简单，而且获取用户名并不是现实社会中的业务逻辑的一部分（仅仅是界面需要，因为在这里其实用成2个TextBox的话完全不需要这一步）
讲解2：定义一个User类的实例。User类的定义可能如下：
public class User
{
public User(string uid)
{
if(DataManager.IsIn(“user”,”uid=’"+uid+”’”))
throw "用户不存在";
else
//User()其他初始化;
}
public bool CheckPsw(string psw)
{
if(DataManager.IsIn(“user”,”uid=’"+uid+”’ and psw=’”+psw+”’”))
return true;
else
return false;
}
}
注意到用户类构造函数中用了个throw来抛出用户不存在的异常，在下面catch的时候用MessageBox(e. Message);来弹出“用户不存在”的错误。这里其实也是为了演示一个层间传递信息的手段，异常也是一种手段，虽然在这里其实可以有其他方式比如返回值，引用参数之类的直接用一个方法来获得用户是否存在的信息，没必要放在构造里，我这么做只是为了演示传递过程，在后面的有讨论这种用法在分层模式下某种特殊情况的应用以解决一些问题。这个类里又用了DataManager类的一个静态方法IsIn(string Table,string str)该方法其实其实是执行 “select * from Table where str”
这个Sql语句并在返回空的时候方法返回false，否则返回true。一个很简单的方法。这里演示了C层对D层的调用。
顺便说一句，因为在VS.Net中，项目的名称会默认地成为项目中的namespace，可以通过把所有自动生成的代码中的namespace改为“解决方案名称”来使3个层可以无缝地自由调用。或者在调用的地方using一下其他层的空间名，看个人喜欢了。比如上面的Login.aspx.cs里需要using2个，而User.cs里要using一个。
讲解3：这里的检查用户密码同样用到User类的一个方法CheckPsw（）而这个方法 又用到了IsIn（）这里就不多说了。
大家注意到我们在U层的页面里用MessageBox()方法来弹出对话框，其实这个方法写在PageBase.cs里，是U层的另外一个文件，继承Page类，Login类又继承它，这个方法其实是把Response.Write(“<script>alert(\“”+ msg+“\”)</script>”)封装起来了。
到此为止，登录结束，例子的实现也说完了。不过只讲了“然”，没有讲“所以然”。下面开始讲“所以然”。
第二部分 作为对比，我们使用一个不面向对象的，不分层的Asp式的Aspx相同登录作为对比。具体的Asp代码我就不写了，反正登录哪都有。先来看看他们2者发生的遭遇（这是不幸的，却偏偏是经常发生的）：
1、 项目经理突然说“不用SqlServer了，换成Access”（正版费用问题）。看看2边分别发生什么：3层这边（A），把DataManager类里的连接改改（在实际情况下，极可能其实是改它的基类，它本身不用改），Web.config中把字符串换掉就完了。Asp式那边（B），同样要改Web.config，同样要改连接什么的，修改量在这个具体的“小溪”例子上几乎相同，在“大桥”例子上B应该会稍微多改点，不过也不会多很多。但是！请注意一点，我们在修改代码的时候，主要时间和精力不是花在“改”这个动作上，而是花在“要改什么地方”上和“寻找需要改的地方”上。在“大桥”上，B需要花费多的多的时间，对大部分文件进行查找和替换。A则仅仅在数据层里，另外2个层不需要任何修改。从这个角度出发我们想到2点原则：
a) 数据层必须要能够保证数据库的变动（任何结构变动、类型变动）对其余各层的不透明性。也就是数据库怎么变，其他层绝对不应该变哪怕1行代码！（web.config是整个应用程序的配置，虽然在物理上存在于U层的文件夹中，但个人更愿意认为它是独立的不属于任何层的，所以这里不计它）
b) 数据层越小越好（如果没有这点原则，我们把整个所有的东西都放在数据层，那当然数据库变动对外面无影响――因为外面几乎没东西――但是这显然不可行）。而且因为前面我们说了，大部分时间花在“找”上面，你小点，找起来也容易点。
2、 客户突然提出B/S版的不好，要换成C/S版的。对于（B）来说，这是晴天霹雳！！他的所有工作都要重新做，（或者几乎所有工作），虽然他有很多代码还可以用，不过他在未来一小段时间就必须不断在“复制－粘贴”中使用以前的代码。（A）发生了什么？？如果你细心看会发现（A）之需要新建个项目“Windows用户界面”（和前面一样，添加引用，项目依赖），拖几个控件到上面，把控件名字起成txt，ddl，btn，然后把click代码和Pageload代码复制过去，（居然。。。）连1行代码都不需要修改！！！！当然，这是比较极端的例子（win和web都有TextBox，DropDownList，Button3种控件，而且我们在PageBase里定义的方法MessageBox()又刚好和win里面方法同名。。。）不过尽管有这么多巧合我们仍然可以也愿意相信，在“大桥”上，（A）将比（B）少做很多工作。从这个角度出发我们又想到2点类似原则：
a) 界面层应该保证界面的任何变化都不需要修改其他层的内容（不管这个具体的例子把ddl改为另外一个TextBox，或是把B/S改为C/S）
b) 界面层越小越好（理由同上。）
3、 除开了界面层和数据层，（如果你的方案中只有3个层的话）剩下的就都是逻辑层的内容了。所以和前面的相对应，我们可以得出结论：
a) 逻辑层应当不受数据库和界面变动的影响而需要修改。
b) 逻辑层越大越好（因为另外2层越小越好。。。）
有了最基本的原则，我们应该来讨论下，根据原则，要怎么分层的问题：
1、 PageBase.cs 应该放在哪个层？根据上面的原则，应该放在C层。但是实际上我习惯放在U层，或者放在另外一个（第4个层，通用底层，在比数据层还低的位置）层里。到底放在什么地方，我最开始的做法是在C层，因为按上面归纳的原则，就应该放在C，但是后来一段时间我习惯于“四层式”之后就把它放在通用底层（下简称B层，该层同时也放如本来在D层中的SqlHelper类等，包括原来3层中所有“通用”的类，这里通用的意思是说其他系统也可以用的到而不需要修改，这个层通常不用解决方案名称而用公司、小组名称等作为namespace，在有新项目的时候在建解决方案的时候就可以“添加现有项目”，简单的加进去并不断积累，实践中对提高效率和代码重用有比较大作用。）不过如果只有3层，我现在倾向于把PageBase放在U层。主要因为最近一段潜心研究面向对象的分析设计的心得。说起来又是一大匹布没完，不过我又在前面的“原则”上加1条：“如果某个类，仅为了某层的某种特殊实现而存在，那么它必须放在该层”，比如PageBase是为了U层的特殊实现（B/S实现）而存在，又比如SqlHelper是为了D层的特殊实现（SqlServer数据库）而存在。所以对应的，它们必须分别放在U层和D层（如果不加这条的话按前面他们都该放在C层，因为C层越大越好，而且数据库和界面的变动不需要改动这2个类－虽然它们可能因改动而没有用了，不过还是不需要去修改它们）
2、 Oldjacky曾经和我谈到一个问题：Datagrid中允许作删除操作，但是如果当前仅余下最后一条记录，则不允许这个删除操作！那么该删除应该放在C层还是D层还是U层？我觉得应该从另外一个角度来考虑：
a) 这种“不允许”是“业务规则的不允许”（比如表内的数据表示当前在店里的职员，删除表示职员离开店里－可能去拿货什么的，添加表示职员回来，当柜台只有一名职员时，显然他绝对不能离开去送货），这个时候，此“禁止删除”的操作应该产生在C层。
b) 这种“不允许”是“程序实现的不允许”（比如当这里为空的时候会引起其他地方比如ToString()方法产生“未将对象的引用设置到对象的实例……”的错误，或程序设计者或项目经理的主观愿望希望它“不允许”以此来减少工作量或简化程序）。这个时候，此“禁止删除”可以放在U层（比如上面说的ToString）或D层（比如违反数据库约束）
3、 细心的人可能会发现，前面的登录例子里，用户一共可以获得3种弹出错误分别是“空密码”“密码错误”“用户不存在”，而其中前2个是在U层里做的，“用户不存在”却是在C层里做的（我是指这个字符串）还是开始说的建桥，我这里是用“小溪建桥”来讲解“大江建桥”所以故意在这里转了个没用的圈，就像在计算小溪上这块木板到底够用多少年，其实对小溪没什么意义，只是为了讲解大桥需要而加上去的，毕竟大桥需要这种考虑。我这里假设“用户不存在需要弹出提示”是一种业务逻辑上的需要，而“未输入密码需要提示”则不是业务规则需要（比如实际业务中可以允许空密码，但是项目经理不同意，说一定要密码）在这个登录例子中其实根本没有什么问题，但是在大项目里，如果这个东西不是业务规则的需要，就不应该放在业务层，如果是一种业务规则，就要放在业务层。有助于业务模型与现实实体的衔接，也有益于业务逻辑更好地表现现实实体的特征。
到此为止，我再次归纳出我们的最终的原则：
1、 如果某个类，仅为了某层的某种特殊实现而存在，那么它必须放在该层。
2、 数据层应当在保证数据库变化对其他层不可见的前提下尽量小。
3、 界面层应当在保证界面变化对业务逻辑层不影响的前提下尽量小。
4、 如果某个类不是业务规则的需要，就不应该放在业务层，反之亦然。
5、 逻辑层应当在保证数据库或界面变化不会造成自身影响的前提下尽量大。
以上5点如果发生冲突，在找平衡点的时候，前面的要高于后面的。比如1和3冲突的时候更倾向于使用规则1。
第二部分结束
有一点应该是“编程代码习惯”和“面向对象”的范畴，不过因为和分层有些关系，所以也说一下。“如果你的代码，自己把它翻译成中文并加必要的标点符号后，其他不懂程序的人看了仍然觉得很乱，那么你很可能层没分好”。比如前面的btn的click：
｛
字符串 用户名是 下拉框 选择值；
字符串 密码是 输入框 值；
如果 密码是 空
对话框（密码空！）；
否则
｛
用户 这用户；
尝试
｛
这用户 是 新的 用户（用户名）；
｝
捕捉（错误）
｛
对话框（错误 消息）；
返回；
｝
如果 这用户检查密码（密码）
{
这用户 设置状态；
响应 重定位（“。。。。。”）；
}
否则
{
对话框（密码错误）
}
｝
代码最好能让不懂的人也能看懂到底在干什么。
最后，oldjacky的Datagrid删除的例子“删除”显然在D层，但是不允许却可能在C或U，如果在U没什么说的了，如果在C，那么这种“不允许”的一个比较合理的实现方法就是在C层里遇到这种情况throw一下。当U层里catch到该throw的时候，禁止删除操作，这样当2个层同时有原因引起禁止时，可以从代码一眼看出这种禁止的来源。类似于前面的2种弹出错误。
注：本文为原创，甚至在写本文的时候，并没有看任何网页文章和书，完全是一时之作，错误难免，而且连代码也是在写字板上打出来的，所以不见得可以运行，大小写也可能有错。一口气写这么多，行文很乱，废话也多，请见谅！
http://community.csdn.net/Expert/topic/5011/5011544.xml?temp=.3323938
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(107) |
评论 (0) |
编辑
敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。
敏捷的价值观如下：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
由价值观引出的12条敏捷原则：
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单——使未完成的工作最大化的艺术——是根本的。
最好的构架、需求和设计出自于自组织的团队。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
建立敏捷联盟的17位大师所创立的敏捷方法包括：极限编程，Scrum，特征驱动开发，动态系统开发方法，自适应软件开发，水晶方法，实用编程方法。这些方法统称为敏捷方法。
其实每个人都可以从敏捷宣言和原则出发，明确问题，找出一些解决方法，形成自己的过程。我觉得国内的软件环境这么复杂，程序员的自主精神又这么强，敏捷方法应该是在中国首先提出才对，只是国人都有唯标准唯规范至上的心理定式，即使找出好办法，也觉得不规范，没有深入形成理论，无法提升高度，始终是跟着鬼子屁股后面走，我想这也是国外软件行业不成熟的表现之一吧。
2. 敏捷仅仅是一个软件过程
如果仅仅从软件过程的角度去认识敏捷实施敏捷，效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：
把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。把人的能动性调动起来，给动力而不是给压力。
要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。
没有绝对的权威，每个人都有可取之处。
3. 迭代就是敏捷，UP属于敏捷。
看到这么多人都把UP归入敏捷，我都开始怀疑是不是自己搞错了。但是在我的印象中：
UP是重型的过程，虽然引入了迭代，但是其原则和价值观与敏捷是不同的。敏捷注重的是反馈，迭代周期尽量的短，重在客户的参与，通过客户的参与，获取持续的反馈，不断调整使整个项目走在正确的方向上。同时也给客户一个感受和思考的机会，因为对于大多数客户而言，目标是明确的（不排除有些客户目标也不明确），但是具体怎么做，开始时是没有想法的，只有看到具体的东西的时候，才知道“噢，原来可以这样，那我想把这里调整一下”。
4. 敏捷是彻底革命的。
敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。
5. 敏捷是反文档的。
文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题？难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。
应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价（特别是更新同步文档的代价）。
因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
文档不是目的，有效沟通才是目的。
6. 为了敏捷而敏捷
“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：
Q：“我们现有的过程很好，不知道怎么用敏捷改进？”
A：“既然很好，那就不要用敏捷”。
做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。
7. 敏捷是CMM的反义词
在桂林会议的讨论中，很多人把CMM作为敏捷的反义词，我觉得这不是很合适。CMM只是一种衡量软件成熟度的标准，并非过程，和敏捷不是一类概念。如果要给敏捷找一个反义词，我觉得传统的瀑布式开发应该更合适一些。
并且，我认为，如果CMM还能继续流行下去的话，应该会有公司可以用敏捷改善的过程通过CMM认证。
8. 敏捷是自由的，无约束的。
敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是应该清楚，凡是都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧？
9. 重做就是重构
重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。
http://sd.csdn.net/n/20060911/94637.html
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(130) |
评论 (0) |
编辑
《企业级应用开发--使用VS.NET、UML和MSF》最近在图书馆借了这本书，才知道VS.NET的两个企业级版本的区别（以前一直以为我用的企业版已经全了，其实只是VSED，没有UML前向工程功能！...>_<）
VSED 和 VSEA 的区别：VSED： Microsoft Visual Studio.NET 2003 Enterprise Developer
VSEA： Microsoft Visual Studio.NET 2003 Enterprise Architect（包含VEA - Visio for Enterprise Architect，可以UML建模和前向工程）
实际上，该建模工具正是VSEA和VSED的区别所在！
$cut$
VEA 2003 和 Visio 2003的区别：VEA 2003： Visio for Enterprise Architect 2003
Visio 2003： 伴随Office 2003套件发布的新版 Visio
其中 VEA 2003 基于 Visio 2002，还可通过增件与VS.Net集成，将现有项目反向工程为UML图形，或者从UML模型前向工程生成C#、VB.Net代码...
而 Visio 2003 只有 Visio Professional 2003 包含 VEA 2003的部分建模功能（只能反向工程）
书籍还在阅读中....等待后续：）
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(204) |
评论 (0) |
编辑
C++ Primer中文版(第4版）（一本久负盛名的C++经典教程）
根据这两天和几位前辈的讨论，总结如下。这只是一个建议的列表，不是说所有的书都要看，不过这里列出来的，应该都是经过检验的精品图书，值得一看。
编码方面：
第一阶段：
21天学通C++（第五版）
C++编程思想（第2版） 第1卷：标准C++导引
The C++ Programming Language
VC++.NET入门
高质量程序设计指南--C++/C语言
第二阶段：
Essential C++
C++ Primer
第三阶段：
代码大全（第二版）
C++标准程序库
Effective C++
More Effective C++
第四阶段：
UNIX环境高级编程
深度探索C++对象模型
重构：改善既有代码的设计（中文版）
设计方面：
第一阶段：
C++编程思想 第2卷：实用编程技术
设计模式精解
第二阶段：
设计模式
泛型编程与STL
第三阶段：
C++设计新思维——泛型编程与设计模式之应用
C++网络编程 卷1：运用ACE和模式消除复杂性
C++网络编程 卷2：基于ACE和框架的系统化复用
ACE程序员指南：网络与系统编程的实用设计模式
http://community.csdn.net/Expert/topic/5018/5018802.xml?temp=.2895319
posted @
2006-10-11 10:00 kittow╃天笑╃ 阅读(180) |
评论 (0) |
编辑