学习之旅week11

课设小结

时间长达两周的票务管理系统课设逐渐进入了尾声，刚看到课设题目实例的时候，完全不认为自己能完成，可能就是一个影片信息的增删改查，登陆注册。第一周写了个登录注册、经理端的影片信息管理、售票员端的场次信息管理，然后就进入了瓶颈期，我不知道座位怎么读取和表示出来，然后问了问同学，A同学说：“我也不会，不写了”，B同学说：“就读入二维数组就行了”。然后经过了两天时间才终于把座位写出来，还算投机取巧，将影厅里面的过道用数字3表示才能表示出影厅的不同形状。尾期在排序上面也出了一丢丢问题，最后通过B同学的指导才得以解决。然后会长要求的三层架构还是没有完成，接下来会继续完善自己的系统，
构思如下：
1.加个鼠标操作
2.添个美丽的小姐姐
3.自己系统的bug再完善完善
4.三层架构冲冲冲

三层架构

• 什么是三层？
  UI(表现层):主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

BLL:(业务逻辑层):UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。

DAL:(数据访问层):与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）

• 举个栗子：

服务员：只管接待客人；

厨师：只管做客人点的菜；

采购员：只管按客人点菜的要求采购食材；

他们各司其职，那么他们三者是如何联系的？

比如：厨师会做：炒茄子、炒鸡蛋、炒面——此时构建三个方法（ cookEggplant()、cookEgg()、cookNoodle())

顾客直接和服务员打交道，顾客和服务员（UI层）说：我要一个炒茄子，而服务员不负责炒茄子，她就把请求往上递交，传递给厨师（BLL层），厨师需要茄子，就把请求往上递交，传递给采购员（DAL层），采购员从仓库里取来茄子传回给厨师，厨师响应cookEggplant()方法，做好炒茄子后，又传回给服务员，服务员把茄子呈现给顾客。

这样就完成了一个完整的操作。

任何一层发生变化都不会影响到另外一层！！！

综上：三层架构的

优势：
1.结构清晰、耦合度低
2.可维护性高，可扩展性高；
3.利于开发任务同步进行,容易适应需求变化

劣势：
1.降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2.有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码

3.增加了代码量，增加了工作量
学长的讲解：

然后就是不断地尝试啦！