20080711 ftp 多线程 上传
http://www.shengfang.org

个人认为: 
  (1)   就传文件而言,   多个ftp线程当然效率高,   但缺点就是你说的"是不是太麻烦" 
  (2)   多个应用线程,   1个ftp线程,   只需要同步,   优点:简单,   缺点:文件多而且大时效率低(需要等) 
  (3)   你说的ftp池,前2者的折中.   优点不用说,缺点:需要额外管理池,另外需要考虑ftpserver的压力,超时(没数据后会自动断开)  

  用过flashget, nettransport的都知道多线程下载速度快，效率高。那么反过来，上传是不是也支持多线程呢？

这里有个关键的地方，那就是FTP 协议里的REST命令，使得下载的时候可以由client端用多种手段对多线程下载下来的文件片段进行组合。而上传的时候，server端靠什么来组合文件片段呢？

查询了RFC959，从头到围浏览了一遍，没有关于server端组合文件的命令。

CuteFtp里明明有multi part upload的选项，这难道不是一个通用的功能么？又查了一下Globalscape的网站，有这么一段话：

The COMB command is a proprietary command and is not defined nor endorsed by any FTP related RFC. However, competing servers who wish to implement this command may do so using the following syntax.

原来是Globalscape自己的产品Secure FTP Server自带的一个功能，RFC没有采用。

如此得出结论，符合FTP RFC959协议的工具并不支持多线程上传的功能。

述     FIX: Today we are shipping a hot-fix roll-up that addresses several issues that we've seen reported with VS 2008 web scenarios.

在网站（ web-site ）项目中，在Bin文件夹包含大量的程序集和 .refresh 文件时， Build会很慢。 总之，在使用vs2008的朋友，该补丁一定要打上，它会给IDE性能带来一定的提升。不过，目前该补丁只适用于英文版，中文版不能使用。
下载链接：https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=10826]

官方5月22发布1640最新正式版，1626的Keygen已经不能用，只好自己动手一下grin
完全是按照CCDebuger的教程做的，所以没在其它地方发布，来这看到的下载后也不要散播，WholeTomato已经开始封杀国内IP了

VA的Bug论坛里反映了一下，1626和1640版中文用户名Bug已有解决办法（其实早在去年10月份VA就出了个FAQ，汗啊，估计都没人看过，所以没有人解决这个问题...）。VA的符号库和配置信息默认都是保存在操作系统用户数据文件夹的，在vista下甚至还分开在两个目录，符号库在C:\Users\<USERNAME>\AppData\Local\VisualAssist\，AutoText配置文件在C:\Users\<USERNAME>\AppData \Roaming\VisualAssist\。如果能修改这个路径，重新设置为全英文的路径下面，这个问题不就迎刃而解了么？呵呵，其实很简单，打开注册表，找到HKCU\Software\Whole Tomato项，在其下新建一个UserDataDir的键，其对应的值就是你要设置的新路径，比如G:\Users\Documents\ VisualAssist\。注意设置的时候需要关闭所有IDE。这样重新打开VC，你会欣喜的发现AutoText（VA Snippets）终于能用了。不过先别急，这时候的数据库都是默认配置，需要还原为你修改过的配置，就再把VC关了，把以前用户路径下的 AutoText等几个目录拷贝到新路径下，这样数据库就跟以前一模一样了。至于符号库，那个玩意VA会自动重建，拷不拷都行。

关于该Bug的官方解答：http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=7948

关于该Bug的FAQ：http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=6865

数据层，业务层（也有叫逻辑层），表示层。

数据层主要是指：返回数据，不一定是和数据库打交到
简单理解就是数据库文件或边接数据库文件

业务层（逻辑层）：通过webservice 调用，webservice 是负责调用逻辑层的方法，以及返回处理的数据，和操作的状态。他主要是对数据做一些处理，包括验证用户输入数据的正确性。有些数据是存放在 数据库中，或文件中，就得调用数据层
简单理解DLL类库　组件

表示层就是：显示处理过的数据，或者只是提交原始的数据，比如名字，价格，什么的，不做复杂数据的处理（大部的情况），还有，验证用户输入数据的正确性
简单理解就是aspx文件

好处是程序的逻辑，结构很清楚，便于阅读，修改，维护等，便于一个团队的开发。还有，如果碰到一个比较难缠的客户，经常要变更需求，这样做就舒服多了，只要把响应层 的一些逻辑 改掉就可以了，不必将整个程序做修改。   如果你的程序是有升级的功能，只要把相应的dll 或exe 发给他就ok 了。

可以做着做着，问题就来了，有几种情况最常见：

i)                    查询结果如何处理。
查询结果通常都是返回很大一组数据，比如1000行的结果集。业务逻辑层查询数据库得到一个1000行记录的结果集，这应该没有疑义，但是如果返回给用户界面呢？是包装成对象，生成1000个对象，再把这1000个对象的集合返回；还是直接把查询到的结果集返回？
如果重新包装返回对象集合，稍微有点良知的人都会有些惶恐，那可是要创建1000对象，然后1000对象属性的赋值，很显然会带来大量的开销，而且这种查询是很频繁发生的，普通的“树-列表”的应用模式下，每一次树节点的选择，都会执行一次查询，那么频繁的对象创建和销毁，势必会产生很多内存碎片，又是一个影响性能的地方。
如果直接把结果集返回，岂不是用户界面这一层需要关心数据库的结构，甚至字段名，本来想对数据库进行隔离的目的不就达不到了么？这时候多个中间层，好处何在？

ii)                  需求变化时修改的地方反而多了。
如果到今天还有人幻想着，需求能在开发之前固定（不要说软件外包，那是编码，不是开发），那么他不适合做开发，可以转行了。需求的变更是永恒的，不变仅存于人们美好的愿景中。
一旦需求变化了，例如业务对象增加了一个特性，大家会发现，我数据库需要增加一个字段，业务对象需要增加一个属性，用户界面可能需要增加一个输入框。慢着，我们不是说三层架构是松耦合的么，怎么还是要改一起改呀。也许高明一点的设计师可以通过数据库扩展字段和对象扩展数据的方法，使业务逻辑层和数据库层适用这种变更。但是当增加一种业务对象，或者业务对象的关系发生变化时怎么办？要知道用户永远比你想象中无知，也永远不可能让用户去服从你的架构，尽管你自以为架构很完美。
天哪，现在当发生变化时我需要修改三个地方，还不如两层结构只需要修改两个地方呢。这不是给自己添麻烦么。

相信仅这两点就可以让很多人信心动摇，不行我们要回忆一下业务逻辑层的好处：

a)      装数据库操作，使业务逻辑与用户操作相分离。但是一般DBMS都有存储过程（Stored Procedure，SP），我可以把业务逻辑放到SP中呀，不也是和用户操作相分离么。

b)      以对象的形式提供业务方法，简化界面的调用。这个优点似乎还在，不过仅仅是为了包装成对象，方便调用，那么其实把业务对象和UI部署在一个物理节点上也可以达到这样的效果，哪我搞台App Server出来干吗？

c)      使开发组内的成员各取所长，专注于自己所擅长的领域。算了吧，没几十个人的团队根本不可能分工如此细致。以笔者招聘的经验，就算是划分三层架构，还不是按模块分配工作，一位老兄从头干到底。