这次项目的开发，在写需求分析和详细概要设计说明书的时候，是严格按照软件工程规定的软件生命周期开发的
原本的用意是根据文档指导开发程序，但是因为自己经验不足，需求分析不到位，设计说明书编写的内容也是不完整的
以至于到最后，还是变成了程序指导文档的情况。
在绝大部分情况下，不管是说明文档的编写还是程序代码的实现，都是一个团队共同完成的事情
所以在这个时候，一个人势单力薄的形式就很明显了。。。
so~得出结论->写开发文档的时候一定要考虑全面->一个神一样的团队是必不可少的
然后就是开发过程中遇到的问题了
说起来很尴尬
原本是用动软的代码生成器直接生成的三层，实在懒得自己写
然后生成的项目有些命名空间有问题，而且全完没有用的类一大堆
遂通通删掉之
然后看了看清楚了不少的项目
竟然还自己点了点头，表示很满意
之后
开始着手修改项目为抽象工厂模式
然后嫌弃IDAL中每一个数据库的表都要对应一个接口
遂抽象出一个IDalBase<T>的泛型接口
只要一个接口，所有的dal类都继承于它，要添加新的功能时就在添加相应的接口，再让对应的dal类继承并实现
遂删掉生成的IDAL接口
然后又用CodeSmith生成dal层类的代码（中间还有一段自己写生成模板的时间。。。）
刚开始想法是好的，实现了代码重用和抽象，也根据单一职责原则将各个功能都分到不同的接口（除了基本的功能）
然后随着项目的开发，问题就出现了
在IDalBase接口中的基本的方法定义的太草率，很多到开发结束用都没用到
而在中间的时候已经发现了这个问题，遂想修改IDalBase，但是突然发现
只要动了一个，dal中的所有类都要跟着改变
真正的牵一发而动全身啊。。。
而且必须保证表的属性数据类型必须是一样的，如：
根据id查找一条记录
Model.model GetById(int id)
这就要求所有的dal类都要通过int类型的id来查数据库，要是有一个表id数据类型不是int呢？
由于发现的时候项目已经完成一半了，想要重新修改工作量很大。。
只能通过添加功能接口来避免这个问题
这就造成了
IDalBase中的方法很多都没用到
功能接口越来越多（可能有选择恐惧症=。= 太多的接口都不知道怎么命名啊！到最后看起来都是好长好长的名字。。。。）
so~又得出结论->项目的构架刚开始设计的时候一定要想好，不然要么更改（更改工作量很大），要么继续错下去（导致项目结构很糟糕）
在项目开发之始，原本的设想是给管理员设计一个配置页面
在这个页面中可以把整个网站一站静态化
但是后来在实现的时候发现
由于每个页面都嵌套了母版页
而在母版页中有一个地方是每时每刻需要跟新数据并展示出来的
所以又导致了此功能没办法实现~
so~结论是->经常被访问，而不经常改变的页面才是适合做静态页的
在附上为什么要使用静态页的原因：降低服务器和数据库压力，也有利于SEO优化
还有就是一个url重写的问题
在项目开发快要完成之后，才想要进行url重写
但为时已晚
项目中的每个页面的url都已经固定好了
要在更改的话还是那句话，工作量太大不适合我。。。（你是有多懒。。）
so~总结->还是要用什么技术在项目设计的时候一样要考虑清楚！
还是附上已经准备好的url重写的流程吧：
为啥要进行url重写？
简单来说
1.有利于SEO
2.避免在更改网站结构的时候使得用户收藏夹的连接变成死链接
实现的方法：
这里使用UrlRewriter实现
下载地址：UrlRewriter
将dll文件下载下来之后添加到项目引用
在web.config文件中进行配置
1.configSections必须放在configuration节点下的第一项，否则会报错
<configSections>
<section name="rewriter"
requirePermission="false"
type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter" />
</configSections>2.接下来将下面的代码添加到配置文件，rewriter节点中，最后一个是根据正则表达式来匹配重写的（推荐）
其他都是写死的，要写很多
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
</httpModules>
<httpRuntime executionTimeout="3600" maxRequestLength="1048576" requestPathInvalidCharacters="" requestValidationMode="2.0"/>
<compilation debug="true" targetFramework="4.0"/>
<customErrors mode="Off"/>
</system.web>
<rewriter>
<rewrite url="~/Index" to="~/Index.aspx" />
<rewrite url="~/BookDetail/(.+)" to="~/BookDetail.aspx?id=$1" />
<rewrite url="~/BooksView/(.+)" to="~/BooksView.aspx?categoryId=$1" />
<rewrite url="~/DiscountBooks" to="~/DiscountBooks.aspx" />
<rewrite url="~/GoodBooks" to="~/GoodBooks.aspx" />
<rewrite url="~/News" to="~/News.aspx" />
<rewrite url="~/Register" to="~/Register.aspx" />
<rewrite url="~/RSS" to="~/RSS.aspx" />
<rewrite url="~/SearchBooks" to="~/SearchBooks.aspx" />
<rewrite url="~/products/(.+)" to="~/products.aspx?category=$1" />
</rewriter>完成了这些配置之后url重写就管用了
例如：用户请求Index，重写之后会请求Index.aspx
最后是项目中用到的一些流程和技术
1.找回密码可以使用的流程：
用户填写用户名和邮箱，点击找回密码
发送重置的密码到用户邮箱
用户可以通过重置的密码登陆并修改密码
2.将网站的配置信息设计一个配置页面提供管理员使用
原来的配置信息是存放在web.config文件中的
好处：不需要改源代码重新编译，直接修改配置文件的xml，保存就可以了
坏处：如果网站已经投入使用，修改配置文件会造成网站重启，会丢失正在操作的用户的状态等信息
最好的方法：在网站的后台管理中，专门写一个配置信息的页面，在这里提供了友好的界面以修改相关的配置信息（配置信息在数据库中存取而不放在配置文件中了）
这时会出现一个问题，当用户的数量很大的时候，如果每个用户请求都要读取数据库中的配置信息，服务器压力很大，这时候可以使用缓存，用户请求配置信息时直接从缓存中拿出，当管理员修改数据库中的配置信息时缓存失效（移除相关的HttpRuntime.Cache）
3.权限控制方式
详情请看
4.网上购买支付功能
asp.net购物车，订单以及模拟支付宝支付（一）---购物车表及添加购物车流程
asp.net购物车，订单以及模拟支付宝支付（二）---订单表
asp.net购物车，订单以及模拟支付宝支付（三）---提交订单
asp.net购物车，订单以及模拟支付宝支付（四）---模拟支付宝支付
5.CKeditor+SWFUpload
CKEditor+SWFUpload实现功能较为强大的编辑器（一）---CKEditor配置
CKEditor+SWFUpload实现功能较为强大的编辑器（二）---SWFUpload配置
CKEditor+SWFUpload实现功能较为强大的编辑器（三）---后台接收图片流程
9.RSS订阅功能
10.敏感词过滤
最后就是项目开发的时候需要注意的一些小问题：
1.接收Get请求的参数的时候一定要先判断一下是否为我们需要的值，因为用户可以随意修改url中的参数
2.sql语句如select 不要直接写* 写具体需要的字段
3.考虑很多细枝末节
4.模板页中已经引用的文件在子页面中不需要在引用了，否则可能会报错
5.考虑每个页面是否能静态化和进行url重写
6.使用ajax进行异步请求的时候，要注意对页面的改变
7.客户端服务端双向校验
8.页面静态化和整页缓冲的场景使用
9.记录用户名和id的静态类要放在ui中，因为各个表现层（如：asp.net，手机ui层等）用来储存这些信息的方式都不一样，如Session，Cookie等
10.ui向bll传参数的时候不要使用TreeNode等这些只能在winform中用的有限制的参数，只能传int，string，model这些通用的数据类型