最近,运用三层架构的理念,对机房收费系统重新进行了设计。虽然对三层的感念做过一些总结,但是还是存在一些认识上的差错,在这儿做一下错误解剖。
以下是U层登录窗体中的代码,主要任务完成用户验证,登录系统主界面:
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles cmdLogin.Click Dim MyUIB As New ManagerB.UserInfoBll Dim userInput As New ManagerE.UserEntity Dim MyDate As New ManagerD.DateDAL Dim currentDate As String = MyDate.MyDate '错误1 Dim currentTime As String = MyDate.MyTime If txtUserID.Text = "" Then MessageBox.Show("密码不能为空,请输入!") End If If txtUserPWD.Text = "" Then MessageBox.Show("用户名不能为空,请输入!") End If userInput.password = Trim(txtUserPWD.Text) userInput.UserID = Trim(txtUserID.Text) If MyUIB.Login(userInput) Then If MyUIB.IsLogin(userInput.userID) Then '错误2 MessageBox.Show("改用户已经登录,不能重复登陆!!") Else Dim MyORB As New ManagerB.OndutyRecordBll MyORB.AddLoginRecord(userInput.userID, currentDate, currentTime) frmMain.Show() Me.Hide() '将登陆记录放进数据库 End If Else MessageBox.Show("用户名或密码错误,请核实后再进行操作!") End If
错误1:直接引用D层;
错误2:U层代替B层进行逻辑处理
接着是登录的时序图,刚开始这个功能的时序图做了两个:
对于仅登录这一个功能,在B层建立了两个类,在D层建立了两个类。D层建立两个类还算说的过去,这是根据两张表的处理,建立了两个类,然后就顺着表的处理建立了B层的两个类。错误也就随之出现了。然后再顺着,U层的设计也就跟着出了问题。
U层要做的是触发某一个功能的开始,之后所有的该功能的实现,应该放在B层的逻辑处理层去完成,结果大部分的逻辑处理都是在U曾完成的,而且如果要创建这个B层的类,也应该是根据这个逻辑处理来创建,而不是针对表的处理去创建。
之所以把U层和B层的功能划分的不清,是因为,刚开始的时候,先完成的代码,然后再去画的UML图。结果创建的类和图无组织无纪律,显得有些散乱。散乱还是次要的,关键是一点不符合面向对象程序设计的要求-封装。
看修改后理想的结果;
If MyLoginBll.Login(userInput, newRecord) Then
frmMain.Show()
Me.Hide()
Else
MessageBox.Show("用户名或密码错误,请核实后再进行操作!")
End If
然后是该登录过程修改后的时序图:
修改之后,登录所有的过程处理都真正交由B层去处理了。如果对我上面的叙述不狗明白的话,可以套用以前的比喻,我原先的代码是,服务员干了厨师应该做的事儿,现在又让他们各司其职了,没有越俎代庖了。
有错误就改正,让系统在不断修改中完善,One bird in hand is better than double-bird in the bush,继续完善,重构这个系统!