Best practise : 封装存储过程 (续2)


 

继续以delete_dept为例。

 

作为存储过程,当“如果dept内有对应的person,那么提示用户不能删除”这个需求提出的时候,delete_dept是无法在运行时提醒用户的,因此它必须和UI代码达成协议:当delete_dept返回-1的时候,就是不能删除的意思,然后由UI代码提示用户“不能删除”。

就是说,检查部分在存储过程,而检查后的结果有UI来执行。两者通过return的负数来决定给用户怎样的提示。

确实如此:我们有不少代码都是通过存储过程返回负值来说明错误的类型,然后有UI解释这个错误,决定如何告诉用户。

既然如此,为什么不直接由存储过程来决定提示内容呢?尽管return不能返回文本内容,但是raiserror可以(要求 sql2005):

 

CREATE PROCEDURE [dbo].[delete_dept]        

  @id int

AS

    if exists (select * from person where dept_id = @id)begin

               raiserror(16,1,"不能删除")

  return

end

delete  from dept where id=@id

RETURN 0

客户端代码:

void delete_dept(int id)

{

   try{

RunProc("delete_dept",id); 

   }catch(Excetion ex ){

MessageBox.Show(ex.message);

   }

}

这样的做法,好处在于判断和消息反馈都在一起。而不是如同以往的做法那样分离开来。本来就是两个相关的功能工作,应该放到一个代码块内,从而让代码的职责更加清晰。现在sql2005和以后的版本都已经支持了这个做法。

你可能感兴趣的:(sql,工作,UI)