做设计的时间是不是短了呢？

暑假从7月15号就开始做教务系统了，经过3~4天时间做需求画界面，经过3~4天时间设计数据库，又经过3~4天时间写DAL层，到今天写BLL层也已经有3~4天了，写BLL层比前几个阶段感觉有点混乱，有点吃力。

教务系统总共分了9个系统，我和吉庆负责评教系统。我这的需求已经确定，只要把基础信息和排课信息接口拿过来，一拼凑，应该就可以出来我想要的结果。谁想，做了三四天的BLL层了，今天还是有几项查询并显示的功能不容易实现。关键是基础信息、排课信息和我的评教系统数据库都是单独的，要想完成评教结果的一项查询需要由一个DataTable的一列作条件得到另一个或多个DataTable，将两个甚至多个不同结构的DataTable再拼凑起来合成一个DataTable。循环肯定是少不了的，然后在拼接，有的还涉及到DataTable行列转换之后的拼接，实在是太繁琐了，而且，一旦拼接各项不对应显示的结果就都是错的，就没有任何统计价值了。

想了想，究其原因，就是我们当时设计数据库的时候以为会用上关联，自己的数据库表会和其他数据表相关联起来，其实如果要是关联上了，那真的非常简单了，直接用SQL语句就能轻松解决的问题。因为不同的数据库中的表是不能关联的，于是，简单的问题，变得尤为复杂。经过一天的考虑，BLL层几项需要得到的几项难点还是没有解决，索性，打破了数据库设计三范式，在表中多加了几个字段，让表中的字段产生了冗余。这样我的查询和现实就方便了一些，目前还有一个难点有待解决。就是由DataTable查询结果，循环查询另外多个DataTable，然后每个DataTable行列转换后拼接到原来的DataTable，最后形成一个新的DataTable，然后排序显示在GridView上。最后在解决这个问题。

因为BLL层就需要把DAL层需要的各项数据真正的落实下来，以便增删改查数据库中的各个表。其中评教系统中“学生评分科目统计表”中的“科目总数”字段（也可以说是“学生评分科目统计实体类”中的“科目总数”属性）从排课信息中不能得到每个学生的课程信息，只能得到学生所在专业的课程信息，专业课程信息>每个学生课程信息，因为有些课程是学生选修的。这样得不到每个学生确定的课程信息的话，后面的此学生是否评估完毕和班级是否重评信息就不能给出真实的统计数据了。

这块功能其中还涉及到东龙负责的选课系统中的专业选修课程，专业选修课程也是选课，也需要给上课教师评分。所以现在回想起来，现在之所以评教系统的部分查询功能不能实现，是因为排课信息、选课信息和评教是密切相关的，这三个组在做需求和数据库设计时没有做深入的讨论。

在做软件的道路上，我们经常说，一个好的软件，前期投入设计的时间和精力占70%，写代码占用20%，后期测试和维护占用10%，从本文一开始列出的时间来看，我们确实没有流出过多的时间和精力去做需求和设计，才导致了今天的BLL层无法得到想要的数据接口，导致功能不能实现。如果前期各个组之间讨论的再深入些，设计的就会更全面些，也就不会出现BLL层写了三四天头脑还很乱的局面。

排课信息的数据库已经确定，只能按专业来排课，不能实现查询每个学生的每个课程。按专业排课或许对于排课自身的需求比较清晰吧，也或许是实现确定每个学生上课的课程对排课信息来说确实有些复杂。所以，我们这的评教得到的排课信息也就只能按照专业排课了，至于它影响的评教当中的每个学生的“课程总数”，以及由它来统计的学生是否评教完毕，此班级是否需要重评这些功能就不能实现，或者评教系统实现了但统计的结果不完全符合实际。

应该是我们做设计的时间短了。