SUFC_WebSite 项目报告

 

这个暑假，DoF团队接下了一个项目——计算机学院学生会网站（SUFC_WebSite），这是我们的第一个对外项目。我负责数据访问层（DAL）部分的开发。在开发的过程中，我学习到了很多书本上没有的知识，积累了不少经验。

任何一个项目在开发之前都应该进行完整的需求分析，尽早的确定每个功能，而且在以后的开发中，要尽量少的迭代开发。在我们的这个项目中，由于时间仓促，没有进行深入完整的需求分析，因此在开发过程中要不断地修改，上述弊端逐渐显露。好在这个项目不是很复杂，改动的工作量尚在可接受的范围内。但如果是一个复杂的项目，所需的工作量就很难保证了。所以在开发项目之前进行的需求分析是十分重要的。当然，变化是时刻存在的，系统需求会随着开发的进展而改变，我们不能保证最初的分析是恒定不变的，但我们可以让修改工作减少到最少。

DAL说白了就是一个类库，供前台调用，对数据库执行增删改查。DAL 为每个实体提供一组方法，每个方法会调用一或多个存储过程。通过抽取方法，把执行存储过程的方法分离开来，把底层对数据库的操作都封装在一类里面，减少了代码冗余，代码最大程度的得到了复用，几乎全部DAL方法都要调用。

DAL在项目中承担的是前台与数据库之间的桥梁作用，访问数据则采用存储过程的，而已不是拼接SQL查询语句，这样避免可把数据库直接暴露给客户，保证了数据库的安全，外部代码不能直接访问数据库数据，只能通过存储过程。如果DAL处理得不好，数据库就很危险，当然我们可以通过数据库设置来保证安全（保持在拥有最低特权的帐户下运行等等），但这并不意味就可以放任DAL。

团队做项目与自己写程序的最大区别是要做非技术性的工作——写说明文档，一份好的说明文档可以让团队开发更加顺利，效率更高。毕竟是第一次做项目，文档写得不是很好，没有经验。一些大的公司，都有专人负责文档的撰写，可见文档是何等重要。

在开始开发这个项目的时候，我们团队内部就这两种方案，经过讨论后决定使用第二种方案，因为这个系统可能发生的错误很简单，也就不需要具体的错误说明了。但是在使用第二种方案的时候也有两种选择：第一种是每一个存储过程使用一套独立的指示值，第二种是所有存储过程都使用一套指示值。我最初选择的是第一种，因为这样的话编写存储过程和文档都相对简单。但是后来发现DAL的代码之后，我发觉这是糟糕的选择。因为这样的话DAL中的每个调用存储过程的方法都要用if…else…语句来检查返回值，造成一大堆重复的代码，而且重构起来也非常困难。如果使用第二种选择，就可以用一个独立的方法来专门检查返回值，达到最大限度地重用代码了。在以后的项目开发中一定要注意这个问题。

数据库的连接字符串是直接明文写在web.config文件里面的，这是十分不安全的。实际项目中，通过web.config文件来设置获取类是很常见的。比如通过事先存放在web.config文件的命名空间和类名，直接指向具体的数据库操作类，配置好具体的Factory对象的完整的类名，实现“工厂模式”。这个也是我没有在SUFC_WebSite项目实现。

测试也是做项目不可少的，以为刚开始接触VS2008，对平台的测试单元功能不是很了解，所以只能双开VS2008，边写代码边测试。这个项目做完后，应该好好学习如何利用开发平台来提高开发效率，学好测试单元的应用和项目的管理。

备份也是做项目的一个重要部分，来学校前系统突然崩溃，却忘记备份，十几天的努力就这样没了。还有之前有上传到谷歌协作平台，再加上4小时的连续不断地打代码，才赶上了进度。

最后是一点私人感情的事，与女朋友交往五年了，一不小心就这样就没了。叶子的离开,是因风的追求,还是树的不挽留?突然没了工作地动力，谢谢文杰师兄，晓村，是他们给我机会，给我动力，让我从颓废中走出来，实在是太感谢他们了。