结论：总的来说,这次的项目对我以及项目组来说是比较失败的。
项目性质：小型项目，拿一位同事的话说就是在市场上随便一家做网站产品的公司，组织几个人，一个月就搞定的网站，费用在一万以下。虽然说的有点过,但是足以说明小的程度。我接手这个项目时，原有的网站是个纯静态站点，现在需要把静态的修改成动态型，同时适当的增加些功能。
项目人员安排如下：
1： 架构师，负责和客户做些需求上的分析，以及给出网站的原型。所谓原型就是用一个工具，快速构造出网站的大致轮廓。
2：程序员，也就是我。我的工作如下：
1：根据架构师给出的原型，做出网站的数据库表结构。
2：从原站点上把静态页面下载下来，用动态页面替换掉相关静态页面。
3：根据原型做UI设计。这是我最失败的地方，后面的UI基本上都是同事帮我修改。
4：应用程序架构以及编码。
3：测试人员。
项目进程：经过我一个月的奋斗，程序功能基本上都已经OK，这个时候出了如下几个意外情况：
1：客户告诉我们数据库版本为SQL2000，而当时我们都认为是SQL2005，这是一个失误，花了不少时间去修改相关的SQL以支持SQL2000。
2：网站有部分功能需要和其它应用程序集成，说的简单点就是其它的应用程序需要调用网站数据库的数据，这又是一个新问题，因为两个应用程序之间并不支持数据库互联，为此我们需要把相关功能分割出一部分部署到另外一台服务器上来解决应用程序之间的兼容性问题。这是开发前没有充分考虑到生产环境因素造成的不良影响。
3：测试阶段，测试人员对网站原有需要提出了很多额外的需求，有些是可取的，有些需要结合具体项目来分析，项目A的做法并不一定在项目B中是必须的。例如一个会员模块来说，如果一个网站对于注册用户拥有很多功能，例如：论坛，博客，投票，虚假币管理等等，这样的网站需要把用户模块设计的相当完善，但如果一个网站对会员提供的功能非常有限，那就没有太大的必要在这方面投入过多的精力。
我在项目中做的自认为比较到位的地方：
第一：数据库设计时在字段的选取上还是比较精确的，有很多程序员都喜欢什么样的字符性字段都用varchar，nvarchar表示，很少会选用char,或者是nchar,像电话，传真什么的选用char类型比选用varchar类型要好，因为这些数据类型长度基本上都在一定小范围之内,基本符合固定长的标准。可以参考：项目小结之数据库设计
第二：对增删改查用面向对象进行包装，使得页面表示层和业务逻辑层得到解耦，便于多人开发同一模块。
第三：对于文件上传方式应用了简单工厂来包装，有些朋友老觉的设计模式不知道怎么用，其它是没有仔细去想设计模式的应用场景，只要是适合当前项目的模式就是好模式，无论应用的是复杂还是简单的模式。
1>:上传文件接口：
{
/// <summary>
/// 上文件,将文件保存到指定目录
/// add by minjiang 09-3-24
/// </summary>
/// <param name="Fileup">上传控件</param>
/// <param name="sSavePath">保存文件夹</param>
/// <param name="iMaxSize">上传大小上限，..k</param>
/// <returns>处理结果</returns>
string[] upFile(ref System.Web.UI.HtmlControls.HtmlInputFile Fileup, string sSavePath, string preFileName, int iMaxSize);
}
2>:ftp上传方式具体实现类：
{
//ftp服务器IP
string ftpServerIP = ConfigurationSettings .AppSettings["ftpServerIP"].ToString().Trim();
//ftp用户名
string ftpUserID = ConfigurationSettings.AppSettings["ftpUserID"].ToString().Trim();
//ftp用户密码
string ftpPassword = ConfigurationSettings.AppSettings["ftpPassword"].ToString().Trim();
//ftp网站目录
string ftpCatalog = ConfigurationSettings.AppSettings["ftpCatalog"].ToString().Trim();
/// <summary>
/// 上传图片,将图片保存到指定目(Ftp)
/// by minjiang 09-4-23
/// </summary>
/// <param name="Fileup">上传图片控件</param>
/// <param name="sSavePath">保存图片文件夹</param>
/// <param name="iMaxSize">上传图片大小上限，..k</param>
/// <returns></returns>
public string[] upPicture(ref System.Web.UI.HtmlControls.HtmlInputFile Fileup, string sSavePath, string preFileName, int iMaxSize)
{
}
3>:http上传方式具体实现类：
{
/// <summary>
/// 上文件,将文件保存到指定目录
/// add by minjiang 09-3-24
/// </summary>
/// <param name="Fileup">上传控件</param>
/// <param name="sSavePath">保存文件夹</param>
/// <param name="iMaxSize">上传大小上限，..k</param>
/// <returns>处理结果</returns>
public string[] upFile(ref System.Web.UI.HtmlControls.HtmlInputFile Fileup, string sSavePath, string preFileName, int iMaxSize)
{
}
4:工厂类：
{
//上传文件方式 1:http 2:ftp
static string UploadFileType = ConfigurationSettings.AppSettings["UploadFileType"].ToString().Trim();
/// <summary>
/// 上传文件帮助类的工厂方法
/// </summary>
/// <returns></returns>
public static IUploadFile GetUploadFileInstance()
{
IUploadFile _IUploadFile=null ;
switch (UploadFileType)
{
case "1":
_IUploadFile = new CUpFile();
break ;
case "2":
_IUploadFile = new CUpFileFtp();
break ;
default :
//默认FTP上传
_IUploadFile = new CUpFileFtp();
break ;
}
return _IUploadFile;
}
}
5>客户端调用：
//处理文件上传
string[] img = _file.upFile (ref this.FileAddress, "/images/", "", 40000);
上传文件小结：这样就通过一个简单工厂的方式实现了文件上传的封装，如果想在应用程序中实现上传方式的动态替代，可以考虑采用策略模式或者是其它模式，只要是能实现自己项目的需求就行，不在乎具体采用什么方式。
第四：拿到需求后，要自己动脑筋思考一下，判断需求是否有不清楚的地方，是否需要稍微调整下，如果一上来就完全按需求做，出现问题时已经晚了。
第五：由于前期需求没有分析到的地方影响功能实现的，而且并没有更好的解决方案时，试着和客户沟通，在需求上或者是实现方式了做适应调整。
我在项目中做的非常失败的地方：
第一：数据库设计时没有考虑到简繁体问题，例如：一个地址字段如果设置成varchar,那么在繁体字符集下的数据库，中文会出现乱码。为此修改了几个字段的数据类型。
第二：页面UI，我编码三年多来，项目中都有美工支持，这次轮到自己UI，那是一个惨啊。这方面就不多说了。
第三：在编码中出现不同程度的BUG，有的是不细心，有的是思维不清楚，这方面也飘过。
失败小结：首先非常感谢我的同事，他们在后期接手了我做的项目，在UI上下了不少功夫，看我的代码也费不少劲，毕竟是在中国不是印度。个人能力有限，在些对我的项目组表示抱歉。